Error in macro is silently discarded in the presence of implicit conversions

[scabug]

This is the smallest reproduction I can find - if I cut this example down any further, the problem goes away. If I run the following test:

// Mock.scala
import scala.reflect.macros.Context

class MockParameter[T](value: T)

class MockFunction2[T1, T2, R] {
  def expects(x: MockParameter[T1], y: MockParameter[T2]) = "expects"
}

trait Mock {
  import language.experimental.macros
  import language.implicitConversions

  implicit def toMockParameter[T](x: T) = new MockParameter(x)

  implicit def toMockFunction2[T1, T2, R](f: (T1, T2) => R) = macro MockImpl.toMockFunction2[T1, T2, R]
}

object MockImpl {

  def toMockFunction2[T1: c.WeakTypeTag, T2: c.WeakTypeTag, R: c.WeakTypeTag](c: Context)(f: c.Expr[(T1, T2) => R]) = {

    c.abort(c.enclosingPosition, "Something bad happened")
    c.universe.reify(null.asInstanceOf[MockFunction2[T1, T2, R]])
  }
}

// MockTest.scala
class Foo { def twoParams(x: Int, y: Double) = "twoParams" }

object Test extends App {
  val m = new Foo
  (m.twoParams _).expects(42, 1.23)
}

I would expect to receive a "Something went wrong" error on this line:

      (m.twoParams _).expects(42, 1.23)

Instead, I get "value expects is not a member of (Int, Double) => String".

If I change the line to avoid the implicit conversion:

      toMockParam2(m.twoParams _).expects(42, 1.23)

Then I do get the "Something went wrong" error as expected. I also get this error if I cut the example down any further (e.g. by avoiding the implicit conversions to MockParameter by changing expects method to take Integer and Double instead.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-5902?orig=1
Reporter: @paulbutcher
Affected Versions: 2.10.0-M3, 2.10.0

[scabug]

@paulbutcher said:
Just a quick note that this is still happening in the most recent nightly (2.10.0-20121009-135643-e5127d94ef). It makes debugging much more difficult than it needs to be for macro writers, and I'm concerned that it will make using macros difficult for "normal" users - if the macro tries to report an error and it's swallowed, it can be very difficult indeed to work out what's going on.

[scabug]

@xeno-by said (edited on Oct 12, 2012 5:07:36 AM UTC):
Well this is how implicit search works. The compiler tries the alternatives, and if they don't fit because of whatever reason, it just silently moves on. If you're absolutely sure that you want to display an error every time the implicit conversion is inapplicable, use c.info.

What's weird though is that -Xlog-implicits doesn't show anything, while it should say smth like "an implicit conversion is inapplicable, because: Something bad happened". Therefore I'll keep this bug open until the next bugfix spree.

[scabug]

@paulbutcher said:
Thanks Eugene. I guess I had a broken mental model of how implicit conversions work - I assumed that whether an implicit was applicable was determined entirely by the type system (i.e. if the types work, then apply the implicit). And that if there was then an error, it would be reported.

I will definitely have to put something in to make sure that the user is aware if this happens, or they'll find it really difficult to work out what's going on. I'll look into whether c.info does the trick.

Thanks!