Stabilize &mut (and *mut) as well as &Cell (and *const Cell) in const

[RalfJung]

This stabilizes const_mut_refs and const_refs_to_cell. That allows a bunch of new things in const contexts:

• Mentioning &mut types
• Creating &mut and *mut values
• Creating &T and *const T values where T contains interior mutability
• Dereferencing &mut and *mut values (both for reads and writes)

The same rules as at runtime apply: mutating immutable data is UB. This includes mutation through pointers derived from shared references; the following is diagnosed with a hard error:

#[allow(invalid_reference_casting)]
const _: () = {
    let mut val = 15;
    let ptr = &val as *const i32 as *mut i32;
    unsafe { *ptr = 16; }
};

The main limitation that is enforced is that the final value of a const (or non-mut static) may not contain &mut values nor interior mutable & values. This is necessary because the memory those references point to becomes read-only when the constant is done computing, so (interior) mutable references to such memory would be pretty dangerous. We take a multi-layered approach here to ensuring no mutable references escape the initializer expression:

• A static analysis rejects (interior) mutable references when the referee looks like it may outlive the current MIR body.
• To be extra sure, this static check is complemented by a "safety net" of dynamic checks. ("Dynamic" in the sense of "running during/after const-evaluation, e.g. at runtime of this code" -- in contrast to "static" which works entirely by looking at the MIR without evaluating it.)
  • After the final value is computed, we do a type-driven traversal of the entire value, and if we find any &mut or interior-mutable & we error out.
  • However, the type-driven traversal cannot traverse union or raw pointers, so there is a second dynamic check where if the final value of the const contains any pointer that was not derived from a shared reference, we complain. This is currently a future-compat lint, but will become an ICE in const-eval interning: accept interior mutable pointers in final value #128543. On the off-chance that it's actually possible to trigger this lint on stable, I'd prefer if we could make it an ICE before stabilizing const_mut_refs, but it's not a hard blocker. This part of the "safety net" is only active for mutable references since with shared references, it has false positives.

Altogether this should prevent people from leaking (interior) mutable references out of the const initializer.

While updating the tests I learned that surprisingly, this code gets rejected:

const _: Vec<i32> = {
    let mut x = Vec::<i32>::new(); //~ ERROR destructor of `Vec<i32>` cannot be evaluated at compile-time
    let r = &mut x;
    let y = x;
    y
};

The analysis that rejects destructors in const is very conservative when it sees an &mut being created to x, and then considers x to be always live. See here for a longer explanation. const_precise_live_drops will solve this, so I consider this problem to be tracked by #73255.

Cc @rust-lang/wg-const-eval @rust-lang/lang
Cc #57349
Cc #80384

[rustbot]

r? @estebank

rustbot has assigned @estebank.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri