Trait bounds on struct type parameters aren't always enforced (depending on the order of impls)

[SSheldon]

The following compiles without issue, even though the impl of Trait2 is missing a trait bound that T implements Bound:

pub trait Bound { }
pub struct Foo<T: Bound>;

pub trait Trait1 { }
impl<T: Bound> Trait1 for Foo<T> { }

pub trait Trait2 { }
impl<T> Trait2 for Foo<T> { }

fn main() { }

However, if you switch the order of the impls...

pub trait Bound { }
pub struct Foo<T: Bound>;

pub trait Trait2 { }
impl<T> Trait2 for Foo<T> { }

pub trait Trait1 { }
impl<T: Bound> Trait1 for Foo<T> { }

fn main() { }

You suddenly start getting this error:

error: the trait `Bound` is not implemented for the type `T` [E0277]
impl<T> Trait2 for Foo<T> { }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

I did not expect the ordering of the impls to matter here. I'm using rustc 1.0.0-nightly (1d00c545e 2015-01-30 19:56:34 +0000).

[pnkfelix]

P-high, not 1.0. (But definitely a weird bug that we would like to fix.)

[nikomatsakis]

cc me

[SSheldon]

@nikomatsakis, @pnkfelix: should this be P-backcompat-lang since the compiler accepts code that it should not?

[pnkfelix]

@SSheldon I think we decided this is one of those edge cases where the amount of breakage (that fixing this is expected to incur) was deemed acceptable for fixing post 1.0.

At the time this was last triaged, there was a general rule that if something was tagged P-backcompat-lang, then it must also be set for the 1.0 milestone (at the latest).

However, since then during recent triage meetings, we have been more willing to tag things as P-backcompat-lang even if they were not attached to the 1.0 milestone.

So, with that in mind:

triage: P-backcompat-lang, not P-high

[arielb1]

This causes an RFC1214 warning in 1.4+.