The new method lookup mechanism typechecks calls against the method type declared in the trait, not in the impl. In some cases that results in tighter rules, and in some cases looser. Correct for that.

src/test/compile-fail/regions-bounded-method-type-parameters-cross-crate.rs

@@ -18,15 +18,15 @@ use lib::Inv;
 use lib::MaybeOwned;
 use lib::IntoMaybeOwned;
 
-fn call_into_maybe_owned<'a,F:IntoMaybeOwned<'a>>(f: F) {
+fn call_into_maybe_owned<'x,F:IntoMaybeOwned<'x>>(f: F) {
     // Exercise a code path I found to be buggy. We were not encoding
     // the region parameters from the receiver correctly on trait
     // methods.
     f.into_maybe_owned();
 }
 
-fn call_bigger_region<'a, 'b>(a: Inv<'a>, b: Inv<'b>) {
-    // Here the value provided for 'y is 'b, and hence 'b:'a does not hold.
+fn call_bigger_region<'x, 'y>(a: Inv<'x>, b: Inv<'y>) {
+    // Here the value provided for 'y is 'y, and hence 'y:'x does not hold.
     a.bigger_region(b) //~ ERROR cannot infer
 }
 

src/test/compile-fail/wrong-mul-method-signature.rs

@@ -58,7 +58,13 @@ impl Mul<f64, i32> for Vec3 {
 }
 
 pub fn main() {
-    Vec1 { x: 1.0 } * 2.0;
-    Vec2 { x: 1.0, y: 2.0 } * 2.0;
-    Vec3 { x: 1.0, y: 2.0, z: 3.0 } * 2.0;
+    // Check that the usage goes from the trait declaration:
+
+    let x: Vec1 = Vec1 { x: 1.0 } * 2.0; // this is OK
+
+    let x: Vec2 = Vec2 { x: 1.0, y: 2.0 } * 2.0; // trait had reversed order
+    //~^ ERROR mismatched types
+    //~^^ ERROR mismatched types
+
+    let x: i32 = Vec3 { x: 1.0, y: 2.0, z: 3.0 } * 2.0;
 }