Lifetime extension in consts/statics sometimes makes *less* code compile

[RalfJung]

@traviscross found this fun example:

const C1: &[u8] = { let x: &'static mut [u8] = &mut []; x }; //~ OK
const C2: &[u8] = { &mut [] }; //~ ERROR

C1 compiles because empty arrays get promoted even behind mutable references.

C2 does not compile because that borrow is in lifetime extension position, and then the const-checks reject it due to being a non-transient mutable borrow. If we didn't do lifetime extension here, then the code would work, since then const-checks would consider the borrow to be transient, and finally promotion would make the rest work.

Not sure if this is worth fixing, but it's definitely odd. If we did want to fix it, we would have to either

• ensure that const-checks accept non-transient borrows that will later get promoted (duplicating the same logic... ugh)
• or run promotion before const-checks (which seems to be the opposite of what @oli-obk has planned)

@rust-lang/wg-const-eval

[traviscross]

It makes describing the language simpler if this were to work, so if it can, it does seem desirable from that perspective. I'm of course curious to hear more about the other tradeoffs.

cc @ehuss

[oli-obk]

Well, I at least want the "can we call this function in this context" logic to be earlier. Mutability checks and such seem fine to leave right where they are or move them after promotion.

The worries I have with that are

• we do not const check promoteds yet, and I'm not sure how changing that would affect things. I guess as long as the rules for the promoted are the same as for their parent item we should not get a change in behaviour
• promotion may rely on const checks having run and already tainted the body