auto merge of #12638 : luqmana/rust/op-no-ref, r=alexcrichton

From my comment on #11450:

The reason for the ICE is because for operators `rustc` does a little bit of magic. Notice that while you implement the `Mul` trait for some type `&T` (i.e a reference to some T), you can simply do `Vec2 {..} * 2.0f32`. That is, `2.0f32` is `f32` and not `&f32`. This works because `rustc` will automatically take a reference. So what's happening is that with `foo * T`, the compiler is expecting the `mul` method to take some `&U` and then it can compare to make sure `T == U` (or more specifically that `T` coerces to `U`). But in this case, the argument of the `mul` method is not a reference and hence the "no ref" error.

I don't think we should ICE in this case since we do catch the mismatched trait/impl method and hence provide a better error message that way.

Fixes #11450

2 files changed, 40 insertions, 1 deletions

diff --git a/src/librustc/middle/typeck/check/mod.rs b/src/librustc/middle/typeck/check/mod.rs
index 9b8ce481de9..4339d2c62be 100644
--- a/src/librustc/middle/typeck/check/mod.rs
+++ b/src/librustc/middle/typeck/check/mod.rs
@@ -1732,7 +1732,13 @@ pub fn check_expr_with_unifier(fcx: @FnCtxt,
                                 ty::ty_rptr(_, mt) => formal_ty = mt.ty,
                                 ty::ty_err => (),
                                 _ => {
-                                    fcx.ccx.tcx.sess.span_bug(arg.span, "no ref");
+                                    // So we hit this case when one implements the
+                                    // operator traits but leaves an argument as
+                                    // just T instead of &T. We'll catch it in the
+                                    // mismatch impl/trait method phase no need to
+                                    // ICE here.
+                                    // See: #11450
+                                    formal_ty = ty::mk_err();
                                 }
                             }
                         }
diff --git a/src/test/compile-fail/wrong-mul-method-signature.rs b/src/test/compile-fail/wrong-mul-method-signature.rs
new file mode 100644
index 00000000000..a39226faee6
--- /dev/null
+++ b/src/test/compile-fail/wrong-mul-method-signature.rs
@@ -0,0 +1,33 @@
+// Copyright 2014 The Rust Project Developers. See the COPYRIGHT
+// file at the top-level directory of this distribution and at
+// http://rust-lang.org/COPYRIGHT.
+//
+// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
+// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
+// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
+// option. This file may not be copied, modified, or distributed
+// except according to those terms.
+
+// This test is to make sure we don't just ICE if the trait
+// method for an operator is not implemented properly.
+// (In this case the mul method should take &f64 and not f64)
+// See: #11450
+
+struct Vec2 {
+    x: f64,
+    y: f64
+}
+
+impl Mul<Vec2, f64> for Vec2 {
+    fn mul(&self, s: f64) -> Vec2 {
+    //~^ ERROR: method `mul` has an incompatible type: expected &-ptr but found f64
+        Vec2 {
+            x: self.x * s,
+            y: self.y * s
+        }
+    }
+}
+
+pub fn main() {
+    Vec2 { x: 1.0, y: 2.0 } * 2.0;
+}