-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
remove this weird special case from promotion #78363
Conversation
fn main() { | ||
// We must not promote things with interior mutability. Not even if we "project it away". | ||
let _val: &'static _ = &(Cell::new(1), 2).0; //~ ERROR temporary value dropped while borrowed | ||
let _val: &'static _ = &(Cell::new(1), 2).1; //~ ERROR temporary value dropped while borrowed |
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.
These two already failed before.
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.
Is this maybe a leftover of the fact that promotion checking and const checking used to be one huge spaghetti monster? Or is it "just because" our promotion rules in const contexts kind of follow explicit promotion rules?
Ah, here is another case that is affected: const FIVE: Cell<i32> = Cell::new(5);
#[inline(never)]
fn tuple_field() -> &'static u32 {
// This test is MIR-borrowck-only because the old borrowck
// doesn't agree that borrows of "frozen" (i.e., without any
// interior mutability) fields of non-frozen temporaries,
// should be promoted, while MIR promotion does promote them.
&(FIVE, 42).1
} (I wish we would have sticked to what the old borrowck allows.^^) |
I think it is a "because we can" that was added when promotion was ported to MIR (probably it was natural to add given that it was the same code as const checking, where such precision is probably useful and less of a problem). |
a check-only crater run should suffice, please feel free to start it whenever you think the PR is ready. I really hope we can get away with this change |
@bors r- |
eh... |
⌛ Trying commit dfd3ec06104aaaa23cecde2f24fedac2d5fb156b with merge b2c2190fa7bf856bb0ed5e8806266e3a2135c6f8... |
☀️ Try build successful - checks-actions |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
All of these regressions are false positives. :) |
🎉 |
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
@rfcbot reviewed |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
Rebased on newer master. @oli-obk this PR is now awaiting your review. :) |
@bors r+ |
📌 Commit d057a93 has been approved by |
☀️ Test successful - checks-actions |
Promotion has a special case to ignore interior mutability under some specific circumstances. The purpose of this PR is to figure out what changes if we remove that. Since
Cell::new
and friends only get promoted insideconst
/static
initializers these days, it actually is not easy to exploit this case: you need something likeI assume something like
&Some(&(Cell::new(1), 2).1)
would hit the nested case insidevalidate_rvalue
... though I am not sure why that would not just trigger nested promotion, first promoting the inner reference and then the outer one?Fixes #67534 (by simply rejecting that code^^)
r? @oli-obk (but for now this is not meant to be merged!)
Cc @rust-lang/wg-const-eval