Turns out opaque types can have hidden types registered during mir validation

This commit is contained in:
Oli Scherer 2023-07-27 08:23:06 +00:00
parent 52bdc37727
commit 99a9a63ca6
2 changed files with 25 additions and 6 deletions

View File

@ -57,6 +57,8 @@ pub fn is_subtype<'tcx>(
// we would get unification errors because we're unable to look into opaque types, // we would get unification errors because we're unable to look into opaque types,
// even if they're constrained in our current function. // even if they're constrained in our current function.
for (key, ty) in infcx.take_opaque_types() { for (key, ty) in infcx.take_opaque_types() {
let hidden_ty = tcx.type_of(key.def_id).instantiate(tcx, key.args);
if hidden_ty != ty.hidden_type.ty {
span_bug!( span_bug!(
ty.hidden_type.span, ty.hidden_type.span,
"{}, {}", "{}, {}",
@ -64,5 +66,6 @@ pub fn is_subtype<'tcx>(
ty.hidden_type.ty ty.hidden_type.ty
); );
} }
}
errors.is_empty() errors.is_empty()
} }

View File

@ -0,0 +1,16 @@
//! ICE: https://github.com/rust-lang/rust/issues/114121
//! This test checks that MIR validation never constrains
//! new hidden types that *differ* from the actual hidden types.
//! This test used to ICE because oli-obk assumed mir validation
//! was only ever run after opaque types were revealed in MIR.
// compile-flags: -Zvalidate-mir
// check-pass
fn main() {
let _ = Some(()).into_iter().flat_map(|_| Some(()).into_iter().flat_map(func));
}
fn func(_: ()) -> impl Iterator<Item = ()> {
Some(()).into_iter().flat_map(|_| vec![])
}