Support vec![const { ... }; n] syntax#133412
Support vec![const { ... }; n] syntax#133412EFanZh wants to merge 3 commits intorust-lang:masterfrom
vec![const { ... }; n] syntax#133412Conversation
|
r? @Noratrieb rustbot has assigned @Noratrieb. Use |
rustbot
added
S-waiting-on-review
This comment was marked as off-topic.
This comment was marked as off-topic.
rustbot
added
the
T-libs-api
This comment was marked as resolved.
This comment was marked as resolved.
This comment has been minimized.
This comment has been minimized.
EFanZh
force-pushed
the
vec-of-const-expr-macro
branch
from
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.
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.
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.
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.
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.
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.
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.
Makes sense. Would be good to have a test.
|
☔ The latest upstream changes (presumably #133533) made this pull request unmergeable. Please resolve the merge conflicts. |
tgross35
added
S-waiting-on-ACP
11 participants
ACP: rust-lang/libs-team#484.