NLL: cast causes failure to promote to static

[pnkfelix]

spawned off of #55223 (comment)

This example is causing an error in NLL:

play

struct Slice(&'static [&'static [u8]]);
static MAP: Slice = Slice(&[
    b"CloseEvent" as &'static [u8],
]);

but this one does not cause an error:

play

struct Slice(&'static [&'static [u8]]);
static MAP: Slice = Slice(&[
    b"CloseEvent",
]);

[estebank]

And it causes an ICE without nll enabled.

[RalfJung]

And it causes an ICE without nll enabled.

A fix for that is on its way: #55262

[oli-obk]

@davidtwco and I have worked out a theory on zulip:

Promotion is happening successfully, but the AscribeUserTy still refers to the old value after promotion is done, because https://github.com/rust-lang/rust/blob/master/src/librustc_mir/transform/promote_consts.rs#L306 only modifies the assignment, leaving the AscribeUserTy in place. We need to find potential corresponding AscribeUserTys and update them.

[davidtwco]

For an update on what the root cause of this and the approach being taken to fixing it, there's a breakdown on Zulip.

[SimonSapin]

but this one does not cause an error:

Casting is typically required for byte string literals because their type is a thin reference to a fixed-size array like &'static [u8; 10]. In an array literal of byte strings, we can get type errors because for example the type inferred for the second item is not the same as the type inferred for the first item. (They’re references to byte arrays of different size.) This is even if the outer array ends up type-annotated as a slice of byte slices &'static [&'static [u8]].

(Perhaps this somewhere type inference could improve?)

Another way to "cast" is slicing with RangeFull, for example [&b"CloseEvent"[..], &b"foo"[..]].