Add caveats about mutable references in consts

[traviscross]

As it turns out, the story that "the final value of a constant cannot contain any mutable references" has some nuance to it. Let's describe these caveats.

Thanks to theemathas for noticing these and to RalfJ for filling in context.

cc @RalfJung @oli-obk @theemathas @tshepang @ehuss

[theemathas]

I believe that this is the first time in the reference that we document that mutable references to zero-length arrays can be promoted.

Note that this only works with zero-length arrays. Also, this promotion does not seem to always happen, see rust-lang/rust#140126

[traviscross]

Note that this only works with zero-length arrays. Also, this promotion does not seem to always happen, see rust-lang/rust#140126

Look at the bottom note in https://doc.rust-lang.org/nightly/reference/const_eval.html#constant-expressions and rust-lang/rust#143129.

[theemathas]

This preexisting note seems incorrect. It talks about mutable statics, and then shows an example with a reference to an interior-mutable temporary. Such temporaries do not live for 'static. And even if they were to, they would be a const-promoted thing, which is subtly different from statics.

[traviscross]

In an initializer such as,

const _: &AtomicU8 = &AtomicU8::new(0);

the rules for "extending based on expressions" apply as follows:

• The initializer is an extending expression.
• The borrow expression is therefore an extending expression, so the operand of the borrow is an extending expression.

The "operand of an extending borrow expression has its temporary scope extended". I.e., we extend the temporary scope of AtomicU8::new(0).

How far do we extend it? "To the end of the program":

Lifetime extension also applies to static and const items, where it makes temporaries live until the end of the program.

[traviscross]

We also specify that interior mutable values are not subject to constant promotion.

https://doc.rust-lang.org/nightly/reference/destructors.html#constant-promotion

Promotion of a value expression to a 'static slot occurs when the expression could be written in a constant and borrowed, and that borrow could be dereferenced where the expression was originally written, without changing the runtime behavior. That is, the promoted expression can be evaluated at compile-time and the resulting value does not contain interior mutability or destructors (these properties are determined based on the value where possible, e.g. &None always has the type &'static Option<_>, as it contains nothing disallowed).

[RalfJung]

It is still confusing to call this a "mutable static", which one could reasonably interpret as referring to a static mut or at least some sort of static item with mutability.

[traviscross]

(Edit: GH didn't show me @RalfJung's comment; this was posted in parallel to it:)

All that said, I agree the wording was imperfect. I've pushed a commit to clarify the point.

[traviscross]

It is still confusing to call this a "mutable static", which one could reasonably interpret as referring to a static mut or at least some sort of static item with mutability.

Yes, agreed; this is avoided in the revision.

[oli-obk]

Should we give the failing examples a rationale, too? The passing ones have rationales, but we don't explain why e.g. we don't want to allow creating references to interior mutable data from a const unless the reference is to a static item

[traviscross]

Should we give the failing examples a rationale, too? The passing ones have rationales, but we don't explain why e.g. we don't want to allow creating references to interior mutable data from a const unless the reference is to a static item

Sure. I've added some rationales. I'm curious, though, what would you say for this one?

# #![allow(static_mut_refs)]
static mut S: u8 = 0;
const _: &dyn Send = &unsafe { &mut S }; // ERROR.
//                             ^^^^^^
// Not allowed as the mutable reference appears in the final value,
// even though type erasure occurs.

(It's easier to say, for this sort of thing, why we allow something rather than why we don't, as we're conservatively only allowing the things that we have good reason to allow and where we can prove that it's OK to allow those things.)

[oli-obk]

Yea that case is just a limitation of the few provenance checks happening in CTFE. We do allow

use std::sync::atomic::AtomicBool;

static S: AtomicBool = AtomicBool::new(false);
const _: &dyn Send = &unsafe { &S };

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[ehuss]

Thanks!

[RalfJung]

This note is a bit confusing since it does not relate back to what we said above about why these references are disallowed.

It should probably also say that this is sound to allow because it take an unsafe block to create a mutable reference to such a static, and that unsafe block carries the obligation of ensuring that no unsound aliasing will occur, Furthermore, the problem regarding "is there a new instance of the pointee for every use of the const or not" does not come up since unambiguously, these references all point to S.