rustc should check that for each impl of a trait, impls of the supertraits exist

[brson]

On my inheritance branch this currently compiles

trait A { }

trait B: A { }

enum Foo = int;

impl Foo: B { }

I don't think there's anything unsound about this because rustc will generate an error as soon as you try to use trait A on Foo, but it should still be caught by looking at the impl of B.

[brson]

This actually doesn't work because of generic impls:

trait A { }
trait B: A { }

impl<T: A> T: B { }

[catamorphism]

Both of these compile now, when they shouldn't. (As of eed2ca6 )

[nikomatsakis]

Modernized version of @brson's example:

trait A { }
trait B: A { }
impl<T: A> B for T { }
fn main() {}

This compiles. I am not sure, however, why it should not compile, it seems...perfectly valid. I also don't know why this is a counter-example to the bug. In the case where the receiver type T is generic, we can consult the declared bounds to find the set of impls that it is considered to implement, and we should make sure that they include any supertraits of the implemented trait.

[nikomatsakis]

In contrast, this should not compile but does (note that T has no bounds):

trait A { }
trait B: A { }
impl<T> B for T { }
fn main() {}

[emberian]

Still a bug

[catamorphism]

Nominating for milestone 2, backwards-compatible

[graydon]

accepted for production-ready milestone

[graydon]

(un-caught wrong-code errors aren't necessarily B-C risks, see the "judgment call" part of milestone 2 criteria)

[msullivan]

I'll probably fix this soon, since it is a decent approach to solving a problem with default methods/inheritance.