-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-MIRArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlC-bugCategory: This is a bug.Category: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
This example was found in #70452 (where it does not require #![feature(const_generics)]
, the only reason I have it here is to get around #43408) (playground):
#![feature(const_generics)]
const HASH_LEN: usize = 20;
struct Hash([u8; HASH_LEN]);
pub fn foo<'a>() -> &'a () {
Hash([0; HASH_LEN]);
&()
}
The ICE is:
error: internal compiler error:
broken MIR in DefId(0:8 ~ playground[8116]::foo[0]) (Hash(move _2,)):
[u8; _] is not a subtype of [u8; 20]: NoSolution
The ICE goes away when the lifetime parameter ('a
) is removed, or when replaced with a type parameter, so my guess is that the MIR type-checker triggers an attempt at normalization (otherwise it would also ICE with a type parameter) but has lifetime inference variables in the Substs
of the ConstKind::Unevaluated
, and that prevents the normalization.
It really shouldn't, I thought we both erased lifetimes and fell back on fully polymorphic evaluation (which should also succeed here), if there are any inference variables.
Metadata
Metadata
Assignees
Labels
A-MIRArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlC-bugCategory: This is a bug.Category: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.