Repository navigation
NLL: cast causes failure to promote to static #55288
Description
Activity
- changed the title
[-]NLL: temporary value dropped while borrowed[/-][+]NLL: cast causes failure to promote to static[/+]on Oct 23, 2018 And it causes an ICE without nll enabled.
- addedA-lifetimesArea: Lifetimes / regionsArea: Lifetimes / regionsI-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️A-NLLArea: Non-lexical lifetimes (NLL)Area: Non-lexical lifetimes (NLL)regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.Performance or correctness regression from stable to nightly.
on Oct 23, 2018 And it causes an ICE without nll enabled.
A fix for that is on its way: #55262
Reacted by Esteban Kuber@davidtwco and I have worked out a theory on zulip:
Promotion is happening successfully, but the
AscribeUserTystill 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 theAscribeUserTyin place. We need to find potential correspondingAscribeUserTys and update them.For an update on what the root cause of this and the approach being taken to fixing it, there's a breakdown on Zulip.
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"[..]].
spawned off of #55223 (comment)
This example is causing an error in NLL:
play
but this one does not cause an error:
play