Classes extending Scala2 traits fail in runtime

[smarter]

class A extends Function0[String] {
  def apply(): String = "foo"
}

object Test {
  def main(args: Array[String]): Unit = {
    val x = new A()
  }
}

Fails at runtime with:

Exception in thread "main" java.lang.ClassFormatError: Illegal method name "initial$scala.Function0" in class A
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:348)
        at scala.reflect.internal.util.ScalaClassLoader$$anonfun$tryClass$1.apply(ScalaClassLoader.scala:43)
        at scala.reflect.internal.util.ScalaClassLoader$$anonfun$tryClass$1.apply(ScalaClassLoader.scala:43)
        at scala.util.control.Exception$Catch$$anonfun$opt$1.apply(Exception.scala:119)
        at scala.util.control.Exception$Catch$$anonfun$opt$1.apply(Exception.scala:119)
        at scala.util.control.Exception$Catch.apply(Exception.scala:103)
        at scala.util.control.Exception$Catch.opt(Exception.scala:119)
        at scala.reflect.internal.util.ScalaClassLoader$class.tryClass(ScalaClassLoader.scala:42)
        at scala.reflect.internal.util.ScalaClassLoader$class.tryToLoadClass(ScalaClassLoader.scala:37)
        at scala.reflect.internal.util.ScalaClassLoader$URLClassLoader.tryToLoadClass(ScalaClassLoader.scala:101)
        at scala.reflect.internal.util.ScalaClassLoader$.classExists(ScalaClassLoader.scala:121)
        at scala.tools.nsc.GenericRunnerCommand.scala$tools$nsc$GenericRunnerCommand$$guessHowToRun(GenericRunnerCommand.scala:35)
        at scala.tools.nsc.GenericRunnerCommand.<init>(GenericRunnerCommand.scala:52)
        at scala.tools.nsc.GenericRunnerCommand.<init>(GenericRunnerCommand.scala:17)
        at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:41)
        at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:103)
        at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)

The problem is in the generate constructor of A which calls the non-existing method initial$scala.Function0:

  public A();
    Code:
       0: aload_0
       1: invokespecial #11                 // Method java/lang/Object."<init>":()V
       4: aload_0
       5: invokespecial #14                 // Method scala/Function0."initial$scala.Function0":()V
       8: return

[DarkDimius]

This is due to difference in trait encoding.
Dotty is not compatible with scala-defined traits. They need to be recompiled by Dotty.

[smarter]

So what's the solution for interoperability?

[smarter]

In particular, the companion objects of case classes extend FunctionN, altthough this may be worked around by having them extend AbstractFunctionN like they do in scalac.

[DarkDimius]

In this particular case, it guess for the bootstrap it would be easier to compile Dotty together with parts of standard library that are used.

For the interop: https://www.google-melange.com/gsoc/project/details/google/gsoc2015/vova/5856729073975296
http://scala-lang.org/gsoc/2015.html#tasty_support_for_scala

[DarkDimius]

The main reason for existence of AbstractFunctionN in scala, is to have more compact bytecode, by not performing mixin as AbstractFunctionN is a class and already has all mixed-in methods implemented.

Unlike in Scala, in Dotty, mixin composition does not require to materialize methods other than fields accessors in traits. It does it by relying on default methods in interfaces that are supported by JVM 1.8+ . So we do not need AbstractFunctionN at all in our library.

[smarter]

We should probably make it a compile-time error to try to extend a Scala 2 trait in Dotty code for now then.

[DarkDimius]

FunctionX is in no way special here. We have some parts of Dotty that are mixing in traits. The biggest I guess would be
https://github.com/lampepfl/dotty/blob/master/src/dotty/tools/backend/jvm/DottyBackendInterface.scala
And for it to compile safely, we need to compile the abstract trait with it.

[DarkDimius]

We should probably make it a compile-time error to try to extend a Scala 2 trait in Dotty code for now then.

This will break many of our tests. I guess at some point we will need to make issue an error if one extends Scala2 trait that does not have TASTY attached. But only after we bootstrap ourselves, otherwise Dotty would not be able to compile itself.

[smarter]

But only after we bootstrap ourselves, otherwise Dotty would not be able to compile itself.

I'm not sure I understand, for bootstrap to succeed we need to be able to generate code that runs correctly. If we have code in Dotty which extend a Scala2 trait it will fail at runtime, so the bootstrap will fail anyway.

[DarkDimius]

If we have code in Dotty which extend a Scala2 trait it will fail at runtime

If trait is compiled with Dotty, than it is no longer Scala2 trait.
We will need to compile Dotty together with traits in standard library that it mixes in.