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,12 +57,15 @@ 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() {
span_bug!( let hidden_ty = tcx.type_of(key.def_id).instantiate(tcx, key.args);
ty.hidden_type.span, if hidden_ty != ty.hidden_type.ty {
"{}, {}", span_bug!(
tcx.type_of(key.def_id).instantiate(tcx, key.args), ty.hidden_type.span,
ty.hidden_type.ty "{}, {}",
); tcx.type_of(key.def_id).instantiate(tcx, key.args),
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![])
}