test: Add a test for variance in trait matching.

[pcwalton]

I believe that #5781 got fixed by the DST work. It duplicated the
variance inference work in #12828. Therefore, all that is left in #5781
is adding a test.

Closes#5781.

r? @huonw

[huonw]

This doesn't need unsafe because the effect pass runs after the type checker?

[pcwalton]

Right.

[huonw]

Also, is this test case correct w.r.t. to the original issue? It was originally *uint <: *const uint while this one is &'static mut uint <: &'a mut uint. That is, it seem like the implemented type here is the subtype, not the supertype. (I could very well have this all backwards.)

I removed my r+ temporarily.

[pcwalton]

@huonw Yeah, you're right, it's broken and this is still a bug. Looking into it.

[pcwalton]

@huonw Should be fixed now for real. r?

[huonw]

Travis failed.

[edwardw]

I think this patch may have only addressed the vtable part of #5781. There is another half, namely in librustc/middle/typeck/infer/combine.rs#L92, it is still contravariant only for self type. IIRC, if we do fix it, then bivariant weirdness starts to creep in. That's what rfc#12 is for, but now that rfc hasn't made progress for a while.

As for the new compile-fail/variance-trait-matching-2.rs, I believe it is the same as #12470 and has been fixed as a side effect of #14869. And the #12470 itself has been closed by my #15120 and your #15154, twice :D

[pcwalton]

@edwardw Thanks for the heads up! Looks like fixing combine.rs to do the conservative thing and make Self as well as all type parameters invariant didn't have any impact on successful bootstrapping. So I'll do that.

[pcwalton]

r? @huonw

[pcwalton]

I have removed all FIXME's about that issue and made the changes suggested.

[huonw]

Could be assert!(r.is_ok()).

[pcwalton]

It's unfortunate, yes, but I think that being able to return arbitrary references in safe code is much more unfortunate. I believe that this bug allows you to transmute arbitrary values to any other arbitrary value in safe code. Let's lock it down for now and see how we can address the usability problem later.

re-r? @huonw

[huonw]

This has had a few "surprising" consequences. Consider the following code

traitFoo:Clone{}implFooforfn(&int){}fnfoo(_:&int){}fnmain(){
foo.clone();}

This compiles fine with 9f8149e (before this landed), but fails with 1e6b699 (the version currently on the playpen): http://is.gd/qkFy3n

<anon>:3:1: 3:25 error: failed to find an implementation of trait core::clone::Clone for fn(&int)
<anon>:3 impl Foo for fn(&int) {}
^~~~~~~~~~~~~~~~~~~~~~~~

Of particular note is that commenting out the impl Foo line makes it compile, that is, the .clone() call is fine despite the compiler complaining that that type doesn't implement Clone!

---

There's another example where trait impls like

impl<'a,T:HasTransform<'a,Matrix2d>
+ CanTransform<'a,T,Matrix2d>>RelativeTransform2d<'a>forT{fn trans(&'aself,x:Scalar,y:Scalar) -> T{

cannot be used like:

pubstructContext<'a>{ ... }fnfoo(){let c = Context::new();{let d = c.trans(20.0,40.0);let _d = d.trans(10.0,10.0);}}

because the d.trans call needs the &'a self lifetime to match that of the Context in c, but the scope of d is too small. Previously I guess the subtyping meant that c the lifetime could be restricted, but this patch disables that. (@bvssvni is working on narrowing down a smaller example.)

(I'm not suggesting at all that this patch should be reverted, just listing two corner-cases people have met due to this, for the record.)

[bvssvni]

@huonw reduced my example down to: http://is.gd/Yl44ye

pubstructContext<'a>{pubview:Option<&'aint>,}pubtraitRelativeTransform2d<'a>{fntrans(&'aself) -> Self;}/*// WORKS WHEN IMPLEMENTING TRAIT DIRECTLYimpl<'a> RelativeTransform2d<'a> for Context<'a> { fn trans(&'a self) -> Context<'a> { *self }}*/pubtraitCanTransform<'a,T>{fntransform(&'aself) -> T;}impl<'a>CanTransform<'a,Context<'a>>forContext<'a>{fntransform(&'aself) -> Context<'a>{*self}}impl<'a,T:CanTransform<'a,T>>RelativeTransform2d<'a>forT{fntrans(&'aself) -> T{self.transform()}}fnmain(){let c = Context{view:None};{let d = c.trans();let _d = d.trans();}}

<anon>:39:18: 39:19 error: `d` does not live long enough
<anon>:39 let _d = d.trans();
^
<anon>:35:11: 41:2 note: reference must be valid for the block at 35:10...
<anon>:35 fn main() {
<anon>:36 let c = Context { view: None };
<anon>:37 {
<anon>:38 let d = c.trans();
<anon>:39 let _d = d.trans();
<anon>:40 }
...
<anon>:37:5: 40:6 note: ...but borrowed value is only valid for the block at 37:4
<anon>:37 {
<anon>:38 let d = c.trans();
<anon>:39 let _d = d.trans();
<anon>:40 }

[alexchandel]

According to@PistonDevelopers, a bug was introduced and mentioned above which breaks rust-graphics in Rust 0.11. @PistonDevelopers asked that 0.11's release is blocked until the bug fixed. It's very possible this is already taken care of, but just in case it wasn't mentioned in the repo...

[bvssvni]

Rust-Graphics has now a work around: PistonDevelopers/graphics#559