Self-referential templated trait overflows the stack

[lee-b]

Compiling the following:

trait Chromosome<C: Chromosome> {
    fn random() -> C;
}

Causes the following output:

task 'rustc' has overflowed its stack
Illegal instruction

The code was an unintentional typo, and probably isn't valid, but I think the compiler should handle this a lot better, as there's no indication of what the problem is, or where it lies. In large compilation units with complex templating etc., that could be a big roadblock.

[pnkfelix]

Indeed, even a "corrected" version (in that I provided an argument for the type param in the trait in the bound) still overflows the stack:

#![crate_type="lib"]
trait Chromosome<C: Chromosome<C>> {
    fn random() -> C;
}

(I just note this because while I agree that the original example was not valid, I believe the variant I have written is valid and should be accepted by the compiler. But we can wait for post 1.0 for it to be accepted. For 1.0 itself, I would be okay with rejecting this program; we should just do it properly.)

Make sure that we test this variant too:

#![crate_type="lib"]
trait X<C: Y<C>> {}
trait Y<C: X<C>> {}

[huonw]

Almost certainly related to #8762, #9095, #12511 and/or #12644. (Don't have time to dig through them right now, sorry for the link dump.)

[pnkfelix]

hmm, indeed, from reading #8762, I guess the consensus tends to be that this code should not be accepted, though for some reason I had thought that the variant I had written with proper instantaations was sound. Perhaps just not compatible with our monomorphizaton model, though I would have thought that for trait definitions this would still be fine.

[pnkfelix]

Note that I regard this issue and likewise #8762 (trait X<C: X<C>> {}) as being very different from #12511 (trait t : t {}). For some reason in my mind the former are entirely acceptable definitions while the latter is nonsense, (again, that is in my head).

[steveklabnik]

This still overflows the stack today.

[tamird]

No longer reproducible.