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

compiler/rustc_const_eval/src/util/compare_types.rs

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

tests/ui/type-alias-impl-trait/broken_mir.rs

@@ -0,0 +1,16 @@
+//! ICE: https:/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![])
+}