Opaque type collection: Guard against endlessly recursing free alias types #143793
Conversation
rustbot
added
S-waiting-on-review
| @@ -223,7 +223,10 @@ impl<'tcx> TypeVisitor<TyCtxt<'tcx>> for OpaqueTypeCollector<'tcx> { | |||
| } | |||
| // Skips type aliases, as they are meant to be transparent. | |||
| // FIXME(type_alias_impl_trait): can we require mentioning nested type aliases explicitly? | |||
| ty::Alias(ty::Free, alias_ty) if alias_ty.def_id.is_local() => { | |||
| ty::Alias(ty::Free, alias_ty) if let Some(def_id) = alias_ty.def_id.as_local() => { | |||
| if !self.seen.insert(def_id) { | |||
There was a problem hiding this comment.
Of course, this only guards against cyclic alias types, not against "overly deep" ones. It's within the realm of possibility that this still overflows the stack on inputs like type T${n} = T${n+1}; type T${N} = (); where 0 ≤ n < N where N is large (like >10_000 which is the maximum I tested and which took a while to compile but didn't exhibit a stack overflow).
However, rustc struggles on such inputs anyway today whether eager or lazy (I already found a bunch of boring hangs).
Keeping track of depth instead of visited types would address that but I didn't want to make large modifications to this collector. I thought about utilizing tcx.expand_free_alias_tys in appropriate places which can deal with such inputs. However, that might be incompatible with // FIXME(type_alias_impl_trait): can we require mentioning nested type aliases explicitly? which I guess is referring to constructions like:
#![feature(type_alias_impl_trait)]
// #[define_opaque(Inner)] // <-- (?)
type Outer = Inner;
type Inner = impl Sized;
// ...or sth. like that >.<
See test description for technical details.
Fixes #131994.
r? oli-obk (sry, your queue is large, so no rush & feel free to reassign)