Concrete trait member should take precedence over deferred method

[adriaanm]

trait T { lazy val x: String = "foo" }
abstract class AC extends T { def x: Any }

compiles to:

public abstract class AC implements T {
    public AC() { super.x();   }

    public abstract Object x(); // where did my lazy val go?
}

public interface T {
    default public void $init$() { }

    default public String x() {
        return "foo";
    }
}

See https://issues.scala-lang.org/browse/SI-10223

[adriaanm]

More generally, all of these are problematic:

trait T { def m = "" ; val v = "" ; lazy val lv = "" ; object o }

// deferred methods always lose against concrete ones, so none of these declarations actually survive in bytecode
// the mixed in members from T take precedence in the linearisation order
abstract class AC extends T {
  def m: Any
  def v: Any
  def lv: Any
  def o: Any
}

[odersky]

It looks like a problem with bridge generation. Here's what we get after erasure:

  @scala.annotation.internal.SourceFile("i2072.scala") <trait> trait T() extends
  Object { 
    lazy <accessor> def x(): String = "foo"
  }
  @scala.annotation.internal.SourceFile("i2072.scala") abstract class AC()
     extends
   Object() with T { 
    def x(): Object
    def x(): String = this.x().asInstanceOf[String]
  }
}

The bridge goes the wrong way. It should implement def x(): Object with the trait's x method,
but instead it links the trait's x method to the Object method in AC.

[DarkDimius]

@odersky, the issue is even before erasure. We don't consider that trait methods can implement abstract methods in the class where they are mixed in:

trait T { def m = "" ; val v = "" ; lazy val lv = "" ; object o }

abstract class AC extends T {
  def m: Any
  def v: Any
  def lv: Any
  def o: Any
}

class C extends AC{}

Error reported by refchecks:

-- Error: i2072.scala ----------------------------------------------------------
12 |class C extends AC{}
   |      ^
   |      class C needs to be abstract, since:
   |      it has 4 unimplemented members.
   |      /** As seen from class C, the missing signatures are as follows.
   |       *  For convenience, these are usable as stub implementations.
   |       */
   |        def lv: => Any = ???
   |        def m: => Any = ???
   |        def o: => Any = ???
   |        def v: => Any = ???

I suppose by the time of errasure we actually have overriding relatioship in wrong direction and erasure sets forwarders corrently based on info that it's provided.
Going deeper to see why.

[DarkDimius]

Note that scala 2.11.8 also rejects this with the same error message.

[DarkDimius]

Ok, this seems to be a fundamental issue for dotty now.

Consider this example:

trait T { def m = "" ; val v = "" ; lazy val lv = "" }

abstract class AC extends T{
  def m: Any
  def v: Any
  def lv: Any
}

class C extends AC

abstract class AD {
  def m: Any
  def v: Any
  def lv: Any
}

class D extends AD with T

In case of D and AD all the phases do what they are supposed to do.
In case of both C and AC neither mixin, nor lazy vals, nor getters/memoize phases do the right job.
This is because all the compiler API internals assumes that methods defined in AC take precedence over members defined in T and all member selections return them.
Digging deeper.

[odersky]

More interesting examples:

trait T { lazy val x: String = "foo" }
trait U { def x: Any }
abstract class AC extends T with U // { def x: Any }

abstract class B { def x: Any }
class C extends B { def x: String = "abc" }

package p2 {
trait T1 { def f: Any }
trait T2 extends T1 { def f: Number = ??? }
trait T3 extends T1 { override def f: Integer = ??? }
class C extends T2 with T3
}

package p3 {

  trait A { def f: Any }
  trait B extends A { def f: String }
  class C extends B { def f = "abc" }

}