-
Notifications
You must be signed in to change notification settings - Fork 13.3k
const checking: do not do value-based reasoning for interior mutability #121786
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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