const_eval: we allow references to statics and promoteds

[RalfJung]

The docs currently seem to imply that we would reject these, but we do not:

use std::sync::Mutex;

static S: Mutex<i32> = Mutex::new(0);
const _: () = {
  let _ref = &S;
};

const _: () = {
    // The lifetime shows that this is not transient.
    let _mutref: &'static [i32] = &mut [];
};

Arguably, the second example with a promoted is a bit of a stretch. It's also a bit unclear what "are only allowed to refer" means, i.e. what exactly gets checked when exactly.

What actually happens is that we allow mutable and interior mutable borrows when

• the place is transient
• or the place is indirect, i.e. based on a deref expression

We allow the 2nd point because that means the new borrow is pointing to something that was already borrowed before, so we already checked transience at that point. But also, the internal representation of a static item as an expression is a deref, so this also allows &INTERIOR_MUTABLE_STATIC or &mut MUT_STATIC, and something similar happens with promoteds.

Should we mention the point about indirect places? It makes the description more algorithmic, which seems like a good thing, if that's the style you are going for. Basically, the question is, when this clause talks about "places", does it mean places expressions or evaluated places? Is it talking about a static property of the source code, or a dynamic property of the runtime data? If it is the former, indirect places have to be mentioned, if it is the latter, then not.

[traviscross]

@ehuss and I talked about this today on a call. We're going to merge what's here, since this seems strictly better in any case. To your question, we are interested in the seeing and considering a PR for the more algorithmic framing you propose.