Turns out opaque types can have hidden types registered during mir va…

…lidation

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://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![])
+}