Tracking issue for `&mut T` in const contexts (const_mut_refs) #57349

ExpHP · 2019-01-05T03:56:52Z

The const_mut_refs feature gate allows the following in const context:

&mut arguments
mutable (re)borrows and raw pointers (&mut and addr_of_mut! expressions)
dereferencing mutable references and raw pointers (* expressions)

Remaining work

Anonymous allocations in statics get duplicated for multiple codegen units #79738 static mut FOO: &'static mut i32 = &mut 42; is problematic, because LLVM currently duplicates the inner mutable reference when you do static mut BAR: &'static mut i32 = FOO;. It would probably suffice to give all nested allocations in a static names relative to their original static item. Named allocations are neither deduplicated nor duplicated.
Currently the interning of the final result of the const relies on types more than it should, given that transmute is available in consts. Fixed in const-eval interning: get rid of type-driven traversal #119044.
Mutable reference protected by a mutex in static context is considered UB #120450
Figure out what to do with regression: encountered mutable pointer in final value when "outer scope" rule applies in const/static with interior mutability #121610

Open questions

can we stabilize this without figuring out the const heap story? -> yes, no reason this has to wait for const_heap
can we stabilize this without cranelift and codegen_gcc support? ICE: hir: index out of bounds: the len is 5 but the index is 5 #122399, ICE: hir: index out of bounds: the len is 5 but the index is 5 rustc_codegen_gcc#473

The text was updated successfully, but these errors were encountered:

leading_zeroes and this kind of functions are const-ready since 1.34.0 We neeed rust-lang/rust#57349 to constantize further.

RalfJung · 2023-12-21T14:39:04Z

Please move this discussion elsewhere, it is off-topic for this tracking issue.

…, r=<try> Store static initializers in metadata instead of the MIR of statics. This means that adding generic statics would be even more difficult, as we can't evaluate statics from other crates anymore, but the subtle issue I have encountered make me think that having this be an explicit problem is better. The issue is that ```rust static mut FOO: &mut u32 = &mut 42; static mut BAR = unsafe { FOO }; ``` gets different allocations, instead of referring to the same one. This is also true for non-static mut, but promotion makes `static FOO: &u32 = &42;` annoying to demo. ## Why is this being done? In order to ensure all crates see the same nested allocations (which is the last issue that needs fixing before we can stabilize [`const_mut_refs`](rust-lang#57349)), I am working on creating anonymous (from the Rust side, to LLVM it's like a regular static item) static items for the nested allocations in a static. If we evaluate the static item in a downstream crate again, we will end up duplicating its nested allocations (and in some cases, like the `match` case, even duplicate the main allocation).

…, r=RalfJung,cjgillot Store static initializers in metadata instead of the MIR of statics. This means that adding generic statics would be even more difficult, as we can't evaluate statics from other crates anymore, but the subtle issue I have encountered make me think that having this be an explicit problem is better. The issue is that ```rust static mut FOO: &mut u32 = &mut 42; static mut BAR = unsafe { FOO }; ``` gets different allocations, instead of referring to the same one. This is also true for non-static mut, but promotion makes `static FOO: &u32 = &42;` annoying to demo. Fixes rust-lang#61345 ## Why is this being done? In order to ensure all crates see the same nested allocations (which is the last issue that needs fixing before we can stabilize [`const_mut_refs`](rust-lang#57349)), I am working on creating anonymous (from the Rust side, to LLVM it's like a regular static item) static items for the nested allocations in a static. If we evaluate the static item in a downstream crate again, we will end up duplicating its nested allocations (and in some cases, like the `match` case, even duplicate the main allocation).

…ung,cjgillot Store static initializers in metadata instead of the MIR of statics. This means that adding generic statics would be even more difficult, as we can't evaluate statics from other crates anymore, but the subtle issue I have encountered make me think that having this be an explicit problem is better. The issue is that ```rust static mut FOO: &mut u32 = &mut 42; static mut BAR = unsafe { FOO }; ``` gets different allocations, instead of referring to the same one. This is also true for non-static mut, but promotion makes `static FOO: &u32 = &42;` annoying to demo. Fixes rust-lang/rust#61345 ## Why is this being done? In order to ensure all crates see the same nested allocations (which is the last issue that needs fixing before we can stabilize [`const_mut_refs`](rust-lang/rust#57349)), I am working on creating anonymous (from the Rust side, to LLVM it's like a regular static item) static items for the nested allocations in a static. If we evaluate the static item in a downstream crate again, we will end up duplicating its nested allocations (and in some cases, like the `match` case, even duplicate the main allocation).

oli-obk · 2024-03-14T10:26:06Z

All the blockers have been resolved. So we'll need to write up a stabilization report explaining the current status plus explanations of some of the weirder cases.

jhpratt · 2024-03-14T10:32:19Z

Thank you @oli-obk, @RalfJung, and everyone else who has put in countless time and effort on this!

RalfJung · 2024-03-14T11:17:50Z

We do have a potential blocker still, unfortunately: the new interner is still on probation due to #121610. The mutability check in the interner is currently a lint (#122204). My entire motivation for that interner was to make that check a hard error and I feel uneasy stabilizing const_mut_refs until we can make it a hard error.

RalfJung · 2024-03-21T12:44:16Z

The tracking issue lists this was part of this feature

non-initialization assignments could be made (x = y; or *x = y;).

But in fact such assignments are already stable... looks like that feature gate was split up at some point.

Centril changed the title ~~Mutation in const fn~~ Tracking issue for &mut T in const fn Jan 5, 2019