ICE when a supertrait bound contains a binding for a type defined in the supertrait

[nikomatsakis]

Example (reduced by @sfackler from something reported on IRC):

pub trait Subscriber {
    type Input;
}

pub trait Processor : Subscriber<Input=Self::Input> {
    type Input;
}

fn main() {}

[tomprogrammer]

Is that allowed syntax? As RFC 195 states "[…] associated types/lifetimes are not in scope for the optional where clause on the trait header.".

I tried to express something like trait Example: Iterator<Item=Option<Self::AssocType>> { type AssocType; } but thought I have to wait until where clauses on associated type definitions land.

[tomprogrammer]

Nevermind, got it. Only AssocType is not in scope for the trait header, but Self::AssocType is a path to it, so it is valid syntax.

Keep up your excellent work :)

[apasel422]

The code snippet above now causes the following error:

foo.rs:5:40: 5:51 error: associated type `Input` not found for type parameter `Self` [E0220]
foo.rs:5 pub trait Processor : Subscriber<Input=Self::Input> {

Changing the Processor trait to:

pub trait Processor : Subscriber<Input=<Self as Processor>::Input> {
    type Input;
}

yields

foo.rs:5:40: 5:66 error: illegal recursive type; insert an enum or struct in the cycle, if this is desired [E0246]
foo.rs:5 pub trait Processor : Subscriber<Input=<Self as Processor>::Input> {

[Gankra]

I'd like to nominate this, I don't think we can remove old_impl_check without it.

[arielb1]

This currently reports error: unsupported cyclic reference between types/traits detected [E0391]. The cycle can be broken by explicit UFCS notation:

pub trait Subscriber {
    type Input;
}

pub trait Processor : Subscriber<Input=<Self as Processor>::Input> {
    type Input;
}

fn main() {}