Tracking Issue for const_refs_to_cell

[oli-obk]

This is a tracking issue for taking references to values of types that (may) contain UnsafeCell within const contexts.
The feature gate for the issue is #![feature(const_refs_to_cell)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC (Allow references to interior mutable data behind a feature gate #80418)
• 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

Unresolved questions

• The feature gate permits const BAR: AtomicUsize = ..; static FOO: &AtomicUsize = &BAR; and only prevents const FOO: &AtomicUsize = &BAR;. This decision was made because the implementation is simpler this way and we would already allow the static FOO case if BAR were a static itself.
  • This could be problematic, because LLVM ends up deduplicating some unnamed allocations like the one in static FOO
• The soundness of this feature depends on the fact that if a StorageDead exists for a local, then for every assignment to the local, on each pass from that assignment to any return, there will be a StorageDead for this local.
• Once we get heap allocations in constants, it would be possible for users to write a const fn foo() -> &'static Cell<i32>, which could then be used to initialize a const FOO: &'static Cell<i32> which is unsound (and only caught by dynamic checks). The tracking issue for const heap is Tracking Issue for const_heap #79597

Implementation history

• Allow references to interior mutable data behind a feature gate #80418

[kupiakos]

Does this need to apply to raw references/ptr::addr_of!? Given only a *const UnsafeCell<T>, there is not yet a stable way to mutate the referent:

#![feature(const_refs_to_cell)]

use core::cell::UnsafeCell;
use core::ptr;

fn main() {
    const _: i32 = {
        let x = UnsafeCell::new(5i32);
        let p: *const UnsafeCell<i32> = ptr::addr_of!(x);

        unsafe {
            // No stable way to mutate `p`

            // Requires const_mut_refs
            // *(p as *mut i32) = 10

            // Requires const_ptr_write
            // (p as *mut i32).write(10)

            // Requires const_intrinsic_copy, which just left FCP
            // ptr::copy(&10, p as *mut i32, 1);

            *(p as *const i32)
        }
    };
}

[RalfJung]

I would be rather nervous about relying on roundabout arguments like this -- that's the kind of reasoning which quickly leads to accidental stabilization.

For some motivation why we care about this feature, see Gilnaa/memoffset#4 (comment).

[kupiakos]

Do you suspect const_mut_ref would stabilize before this?

This limitation would be much less frustrating if it didn't trigger when taking the address of any generic T, even where I have full certainty that the input cannot contains UnsafeCell. If I could bound on Freeze to communicate this impossibility this would solve the problem (and plenty of other soundness bounds I run into). Is there any way to get the bytes out?

I'm trying to read a generic integer's bytes without mutation and am prevented from doing so on the impossible possibility that an interior mutable type is used. Fortunately it can be gotten around for now by passing in a reference to the const fn, but a &u8 arg is a questionable API surface. For context, I'm attempting to create a stable, generic, const-compatible checked integer cast, but this is the last blocker for an ergonomic API.

[RalfJung]

Status update: const_mut_refs will hopefully to be stabilized soon. However, I think I'd prefer to wait a bit whether there are any issues showing up there before we also allow references to interior mutable types. In particular, the "safety net" described in #129195 doesn't work as well for shared references due to #121610 and rust-lang/unsafe-code-guidelines#493. Therefore, I'd like to increase our confidence in the static checks before stabilizing something without a solid safety net.

See here for a Zulip discussion about what it would take to make sure that when we are allowing references to interior mutable data, that data is indeed "transient" and does not escape the initializer expression.