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

[ExpHP]

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: that's happening in const-eval interning: accept interior mutable pointers in final value #128543
• Adjust documentation: const_eval: update for const_mut_refs and const_refs_to_cell stabilization reference#1590
• Stabilization PR: Stabilize &mut (and *mut) as well as &Cell (and *const Cell) in const #129195

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

[Centril]

Thanks for filing this issue. :)

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

The first half of this, i.e. x = y, is covered by #48821 which is being stabilized in #57175.

[alercah]

I could be wrong, but based on previous conversation with @eddyb, this is very much in the plans. They originally wanted to even allow CTFE to mutate statics during the scope of their execution, until it was discussed out that this is undesirable because it would allow a single function call to behave differently depending on whether or not CTFE was used to precompute the function.

[eddyb]

Please cc @oli-obk and/or @RalfJung on all CTFE-related things.

In terms of the implementation, we plan to allow all pointers where the memory they point to is on the CTFE "stack" (i.e. not a static) and maybe "heap" in the future, with maybe some limitations around const fn itself.

But miri can already interpret more than everything you'd reasonably want to run in CTFE.