allow statics pointing to mutable statics #121782
Conversation
rustbot
added
S-waiting-on-review
|
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
| { | ||
| throw_validation_failure!(self.path, ConstRefToMutable); | ||
| // In a const, everything must be completely immutable. | ||
| if matches!(self.ctfe_mode, Some(CtfeValidationMode::Const { .. })) { |
There was a problem hiding this comment.
So we don't have any tests testing the promoted code path? Or is that rejected elsewhere even in unleash mode?
There was a problem hiding this comment.
With promoteds we have to accept this or else we fail this recently added test.
We know from the internet that a promoted will never add new mutable memory, so all references to mutable memory must be shared refs as otherwise we'd hit the error above about a mutable ref to immutable memory. (But the shared refs may have interior mutability. We do complain if we find an UnsafeCell in an immutable location though.)
There was a problem hiding this comment.
🤣
We know from the internet
(sorry, I know what you meant, but I literally lolled)
There was a problem hiding this comment.
😂
(For anyone else reading along, I meant "interner".)
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
mutable-ref-in-static
branch
from
66268ec to
a9596fb
Compare
|
@bors r+ |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#121326 (Detect empty leading where clauses on type aliases) - rust-lang#121464 (rustc: Fix wasm64 metadata object files) - rust-lang#121681 (Safe Transmute: Revise safety analysis) - rust-lang#121753 (Add proper cfg to keep only one AlignmentEnum definition for different target_pointer_widths) - rust-lang#121782 (allow statics pointing to mutable statics) - rust-lang#121798 (Fix links in rustc doc) - rust-lang#121806 (add const test for ptr::metadata) - rust-lang#121809 (Remove doc aliases to PATH) r? `@ghost` `@rustbot` modify labels: rollup
|
I am thinking about this change from a teaching perspective. I have a small question: If I am understanding this correctly, previously we had "const contexts" which use a set of const evaluation rules to produce a value, and this basically cleaves the world somewhat into "const contexts" and "static contexts", where the rules are nominally shared but some final values become permitted that were not sensical previously. Yes? |
Rollup merge of rust-lang#121782 - RalfJung:mutable-ref-in-static, r=oli-obk allow statics pointing to mutable statics Fixes rust-lang#120450 for good. We can even simplify our checks: no need to specifically go looking for mutable references in const, we can just reject any reference that points to something mutable. r? `@oli-obk`
|
const and static always had a bunch of subtle differences, so this distinction is not entirely new. I would still call them all "const contexts" but there are some particularities that only apply to some const contexts. For example, |
Fixes #120450 for good. We can even simplify our checks: no need to specifically go looking for mutable references in const, we can just reject any reference that points to something mutable.
r? @oli-obk