-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
const checking: do not do value-based reasoning for interior mutability #121786
Conversation
This comment has been minimized.
This comment has been minimized.
Lol, so much for this not being a breaking change. It breaks bootstraping.^^
Why does that not get promoted, though...? |
Surrounding code can be seen here. This does not get promoted because the type of the slice is not known to be |
…s are not interior mutable
This comment has been minimized.
This comment has been minimized.
Very strange, this breaks the following code: const NONE: &'static Option<AtomicUsize> = &None; This gets promoted, but then there are reborrows in the const itself. But reborrows should be ignored by const-checking... |
Oh wait is const-checking happening before promotion? |
Hm yes that may be the case. In that case I am very surprised that this does not lead to more errors... now I wonder what crater would say. |
…g, r=<try> const checking: do not do value-based reasoning for interior mutability This basically means a nicer error for rust-lang#121610, see the new test in `tests/ui/consts/refs-to-cell-in-final.rs`. Currently we have a mismatch between the dynamic semantics of `&` (things might be mutable when the pointee type is `!Freeze`, no matter the pointee value) and const-qualif (doing value-based reasoning). This removes that mismatch. I don't think this can break anything that builds on current nightly; any such code would already later run into the error that the interner complains about the mutable pointer (that's exactly rust-lang#121610). So a crater run makes little sense. Overall this peanuts compared to the *actual* problem with value-based reasoning for interior mutability in promotion (rust-lang/unsafe-code-guidelines#493). I have no idea how to resolve that. But at least now the use of the problematic qualif is down to 1... The first commit is independent, I just got worried about promotion of unions and was happy to notice that at least there we don't do value-based reasoning. r? `@oli-obk`
Ah wait this doesn't entirely remove value-based reasoning from promotion, it only makes that not work inside It is probably futile to use different checks in promotion and const-checking here... When it comes to promotion, even rustc itself relies on value-based reasoning: rust/compiler/rustc_pattern_analysis/src/pat.rs Lines 229 to 234 in be29cd1
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
The job Click to see the possible cause of the failure (guessed by this bot)
|
I don't think there's anything we can do here, unless and until we decide to properly tackle value-based reasoning for interior mutability... |
… r=oli-obk Add tests (and a bit of cleanup) for interior mut handling in promotion and const-checking Basically these are the parts of rust-lang#121786 that can be salvaged. r? `@oli-obk`
… r=oli-obk Add tests (and a bit of cleanup) for interior mut handling in promotion and const-checking Basically these are the parts of rust-lang#121786 that can be salvaged. r? ``@oli-obk``
Rollup merge of rust-lang#121893 - RalfJung:const-interior-mut-tests, r=oli-obk Add tests (and a bit of cleanup) for interior mut handling in promotion and const-checking Basically these are the parts of rust-lang#121786 that can be salvaged. r? ``@oli-obk``
Add tests (and a bit of cleanup) for interior mut handling in promotion and const-checking Basically these are the parts of rust-lang/rust#121786 that can be salvaged. r? ``@oli-obk``
For the record -- yes it does: |
This basically means a nicer error for #121610, see the new test in
tests/ui/consts/refs-to-cell-in-final.rs
.Currently we have a mismatch between the dynamic semantics of
&
(things might be mutable when the pointee type is!Freeze
, no matter the pointee value) and const-qualif (doing value-based reasoning). This removes that mismatch. I don't think this can break anything that builds on current nightly; any such code would already later run into the error that the interner complains about the mutable pointer (that's exactly #121610). So a crater run makes little sense.Overall this peanuts compared to the actual problem with value-based reasoning for interior mutability in promotion (rust-lang/unsafe-code-guidelines#493). I have no idea how to resolve that. But at least now the use of the problematic qualif is down to 1...
The first commit is independent, I just got worried about promotion of unions and was happy to notice that at least there we don't do value-based reasoning.
r? @oli-obk