Recursive functions are a normal programming language feature. In bad cases, they might never terminate at run-time when you call them, but that's fine. (You can get a warning at compile time, but that's just for convenience, the run-time behavior of this function is well-defined and not problematic to the type system at large: it just never finishes - or overflows the stack.)
Bad cases of recursively defined type synonyms on the other hand, should be erraneous at compile-time, at least if they're used somewhere. Type synonyms/aliases don't exist at run-time. The issue in Typesystem soundness hole involving cyclically-defined ATIT, and normalization in trait bounds ¡ Issue #135011 ¡ rust-lang/rust ¡ GitHub is with a situation where such a type was âusedâ in some sense - to make use of its trait bound - but ended up âunusedâ in another sense - so that the non-terminating recursive nature of it didn't result in a compilation error.
That's a compiler bug, as it results in undesirable consequences.
This particular âminimizedâ version of the code ends up not really being recursive anymore though. If you pay attention to the definition, the right-hand side is merely = L
. Badly cyclic reasoning is however still present in the trait bounds that are required & used.
The relevant point in the linked issue, where a bit more explanation is given (for a slightly different variant of this code), is this comment, offering some comments in the code, and linking some related discussions. Also after that comment a separate thread was opened for this âminimizedâ code, as it was deemed sufficiently different from the original issue.
Understanding the code in much more detail is hard, the issue involves subtle points in the interaction of various aspects of the type system â ultimately it's arguably just about understanding all the relevant implementation details of Rust's type and trait system. Remember, it is a bug, there's only limited learning opportunity from asking âwhy this code worksâ from pure language userĘźs perspective, because it isn't even supposed to work. Some compiler team members who've commented on the issue definitely have an even better understanding of the underlying issue than I have; I've already linked a relevant comment above.
Please do note that the main purpose of these issues threads on GitHub is to track any progress with fixing the problems, and I expect it might take a while until they're fixable. So even though the Github issues are a relevant place to look for leaning more about the details of this exploitation, to keep the issues' discussion threads manageable, they might not be the best place to ask very basic questions about it. Thank you for asking here instead.