-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support vec![const { ... }; n]
syntax
#133412
base: master
Are you sure you want to change the base?
Conversation
r? @Noratrieb rustbot has assigned @Noratrieb. Use |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as resolved.
This comment was marked as resolved.
This comment has been minimized.
This comment has been minimized.
245a28e
to
f8ec8e2
Compare
Sorry no, this is indeed a libs-api thing, as this is insta-stable and needs an FCP to merge. Assigning to dtolnay who seconded the ACP. |
library/alloc/src/vec/mod.rs
Outdated
// SAFETY: If `value` is the result of some const expression, we can make as many | ||
// copies as needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an interesting argument that I have not seen before. I can't see anything immediately wrong with it, but paging in @rust-lang/opsem for extra scrutiny.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be the case with the current const
capabilities, but I'm not 100% sure it holds with every possible extension, namely leaking const allocation to runtime. I think the rules around const object unification would make this a valid execution, but I don't have all the relevant info in cache.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do intent that consts can still be implemented as many copies of the same thing for codegen. So whatever we do with const allocation should support that.
But it may be good to put a comment in the source here explaining that this is the standard library doing privileged reasoning, and not a stable guarantee.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have updated the safety comment. Please let me know if there is anything missing or inaccurate.
} | ||
} | ||
|
||
// Avoid calling the destructor of `elem`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This raises the interesting question whether the destructor should be executed at all for vec![const { ... }; 0]
. For 0-length arrays, our current behavior here is rather strange: #79580.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested the array of const expression case, the destructor is not called: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f9ffe1eb972bc415b0e6bf6bf48c18c1. This is consistent with the current implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. Would be good to have a test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good!
☔ The latest upstream changes (presumably #133533) made this pull request unmergeable. Please resolve the merge conflicts. |
ACP: rust-lang/libs-team#484.