AbstractMethodError with lambdas

[lrytz]

trait A[T] { def apply(x: T): T }
trait B extends A[Int] { def apply(x: Int): Int }

object Test {
  def f: B = (x: Int) => x + 1
  def g: A[Int] = f

  def main(args: Array[String]): Unit = {
    println(f(10))
    println(g(10))
  }
}

$ qsc Test.scala
$ qs Test
11
java.lang.AbstractMethodError: Test$$$Lambda$115/1705929636.apply(Ljava/lang/Object;)Ljava/lang/Object;

[adriaanm]

Looks like the issue is with the erasure of def g: A[Int] = f? Should we emit another LMF call in g that adapts an Int => Int to an Object => Object?

[adriaanm]

I'm going to assign this to RC1 and leave it open, so that it's clear that this is a known issue. Also, perhaps there won't be an RC2 (one can dream)...

[adriaanm]

If I correctly understand the bug, we should be able to fix this in a minor release, since it will be binary compatible. @lrytz, if you agree, please assign to 2.12.x

[lrytz]

Should we emit another LMF call in g that adapts an Int => Int to an Object => Object?

First, note that there are no scala Function types (Int => Int / Object => Object) in the example.

I think we should not be using LMF to spin up the B instance because there are two abstract methods in B: apply(I)I and apply(Ljava/lang/Object;)Ljava/lang/Object; inherited from A. For subclasses of B the Scala compiler generates a bridge method, but LMF will not do it - that's why we get the AbstractMethodError.

I think we should try to identify such cases and emit an anonfun class. Better ideas?

[lrytz]

In terms of binary compatibility, I think it should be fine to fix it in 2.12.x: the only thing that would change is the kind of B instance. Instead of an LMF-generated one, you'd get a pre-generated anonfun class instance. But both of these actual class types are not exposed.

[sjrd]

In theory the Scala compiler could already create the bridge as a default method in B, giving something like this:

trait B extends A[Int] {
  def apply(x: Int): Int
  <bridge> def apply(x: Object): Object = apply(x.asInstanceOf[Int])
}

[retronym]

We can also ask LMF to implement bridges in cases where the coercions don't require vale class or primitives.

[retronym]

Oh, I see now that this particular case isn't bridgable by LMF because it involves T=Int

[retronym]

However, primitives are not require to demonstrate the bug:

trait A[T] { def apply(x: T): T }
trait B extends A[String] { def apply(x: String): String }

object Test {
  def f: B = (x: String) => x + "!"
  def g: A[String] = f

  def main(args: Array[String]): Unit = {
    println(f(""))
    println(g(""))
  }
}

[retronym]

Here's a patch that uses the old encoding when the SAM method overrides something with a different erased signature.

scala/scala@2.12.x...retronym:ticket/SD-216