const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns

[RalfJung]

This fixes #140653 by accepting code such as this:

static FOO: AtomicU32 = AtomicU32::new(0);
const C: &'static AtomicU32 = &FOO;

This can be written entirely in safe code, so there can't really be anything wrong with it.

We also accept the much more questionable following code, since it looks very similar to the interpreter:

static mut FOO2: u32 = 0;
const C2: &'static u32 = unsafe { &mut FOO2 };

Using this without causing UB is at least very hard (the details are unclear since it is related to how the aliasing model deals with the staging of const-eval vs runtime code).

If a constant like C2 is used as a pattern, we emit an error:

error: constant BAD_PATTERN cannot be used as pattern
  --> $DIR/const_refs_to_static_fail.rs:30:9
   |
LL |         BAD_PATTERN => {},
   |         ^^^^^^^^^^^
   |
   = note: constants that reference mutable or external memory cannot be used as pattern

(If you somehow manage to build a pattern with constant C, you'd get the same error, but that should be impossible: we don't have a type that can be used in patterns and that has interior mutability.)

The same treatment is afforded for shared references to extern static, for the same reason: the const evaluation is entirely fine with it, we just can't build a pattern for it -- and when using interior mutability, this can be totally sound.

We do still not accept anything where there is an &mut in the final value of the const, as that should always require unsafe code and it's hard to imagine a sound use-case that would require this.

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
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 machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

[RalfJung]

@rust-lang/lang nominating for FCP following prior discussion in #140653.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[jieyouxu]

r? @oli-obk (or someone way more familiar with const-eval)

[traviscross]

As discussed in #140653 (comment), this sounds right to me, and I propose that we do it.

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• whole team signoff resolved by const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns #140942 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[RalfJung]

This should probably still wait for rust-lang/reference#1865 ?
@bors r-

[bors]

☔ The latest upstream changes (presumably #142997) made this pull request unmergeable. Please resolve the merge conflicts.

[traviscross]

Thanks for holding this for the documentation updates to the Reference. That's now ready, so we can...

@bors r=oli-obk

[bors]

📌 Commit 3f818e4 has been approved by oli-obk

It is now in the queue for this repository.

[traviscross]

...but it has conflicts...

@bors r-

[RalfJung]

Yeah, I was waiting for the reference PR to finish so I don't have to rebase N times.

[RalfJung]

@bors r=oli-obk

[bors]

📌 Commit bade3fd has been approved by oli-obk

It is now in the queue for this repository.