AbstractMethodError due to missing bridge method with nested refinement types

[scabug]

(copied from scala-internals post: https://groups.google.com/forum/#!topic/scala-internals/1P-Jj0WYE9E )

http://pastie.org/9842270

Trait Super defines an abstract type member Param and a method doSomething(param: Param) that receives a parameter of this type. It also has a second method that calls that first method.

Object Sub inherits from Super and defines Param, in a way that makes it inherit from same trait twice through a different type member, and implements doSomething. When on this object the second method from Super is then called, it will throw an AbstractMethodError. While the compiler recognizes and accepts the overridden doSomething, it seems to somehow screw up so that the abstract member from Super isn't actually overridden in Sub, but left unimplemented instead. The method does exist, though, because if you do the exact same call in the inheriting object itself or on it from the outside, it works. Just doing the call from within the Super trait seems to fail to dispatch and errors out instead.

If the direct inheritance of Foo = T; Param = Foo with T seems nonsensical, because it basically says "T with T", consider the more verbose but semantically more sane alternative in Sub1, where Foo implements "Left with Right", both of which are different extensions of Any, thereby causing Foo to implement Any twice along different paths without the nonsensical "T with T" expression.

The issue was introduced with Scala 2.10, in scala 2.8 up to scala 2.9.3 the error does not occur. Jason Zaugg narrowed down the regression to the change at scala/scala#469

He also instructed me to include the following gist in this report: https://gist.github.com/retronym/fc605f85713307e9ef3d

And he noted, he was hoping that the fix at https://github.com/scala/scala/pull/3981/files "in 2.12.0-SNAPSHOT might have fixed this, but the bug persists beyond that patch. A small extension of that patch (to unconditionally dealias parents of refinement types during “normalization”) does fix the problem, but when I last tried that in #3981 it has other undesirable effects."

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-9101?orig=1
Reporter: Joscha Drechsler (MisterD123)
Affected Versions: 2.10.1, 2.10.3, 2.11.2, 2.11.4

[SethTisue]

closing as the original pastie is no longer accessible

we could reopen if someone is able to provide a reproduction on Scala 2.13

[som-snytt]

You know who never deletes anything.

https://gist.github.com/retronym/fc605f85713307e9ef3d

object RunIt extends App {
  // can also use Sub1 here
  Sub.thisThrowsAnAbstractMethodError()
}

trait Super {
  type Param >: Null
  def doSomething(param: Param): Unit

  // note that this is the exact same call on the exact same object
  // as in Sub and Sub1; here it explodes, and there it does not.
  def thisThrowsAnAbstractMethodError() = doSomething(null)
}

object Sub extends Super {
  trait T
  type Foo = T
  // directly giving "Param = T with T" works; only the inheriting T "twice"
  // through indirection with a type member (here, Foo) kills it.
  override type Param = Foo with T
  override def doSomething(param: Param): Unit = println("Doing Something")
}


object Test {
  def main(args: Array[String]): Unit = {
    import scala.reflect.runtime.universe._
    println(typeOf[Sub.T] =:= typeOf[Sub.Param])
    println(typeOf[Sub.T] =:= typeOf[Sub.Foo])
    println(typeOf[Sub.Foo] =:= typeOf[Sub.Param])
  }
}

yields

Exception in thread "main" java.lang.AbstractMethodError: Receiver class Sub$ does not define or inherit an implementation of the resolved method 'abstract void doSomething(java.lang.Object)' of interface Super.