Default methods, mixin and invokeSpecial on JVM

class A { def m = 1 }
class B extends A { override def m = 2 }
trait T extends A
class C extends B with T {
  override def m = super[T].m // should invoke A.m currently invokes B.m
}

https://github.com/scala/scala-dev/issues/143#issuecomment-232446342 I have a fix in mind, but I will not have time to try it out before going for vacation. Making a note for myself to come back to it in September.

[DarkDimius]

ping @lrytz @adriaanm. Just had a long meeting with @odersky, considering the options here. Note that this bug also affects 2.11.8. Giving a proper fix for this bug would change the behavior of already existing code. If existing projects rely on current behavior, bug created because of this change could be very hard to track and may require the code to be rewritten.

We’ve decided, that at least for dotty we would prefer to warn for cases that may misbehave. We have played with HotSpot and reread the spec several times, and decided to:

• warn on super[X].foo, where:
  1. X is an interface that inherits a class C;
  2. X does not provide implementation for method foo;
  3. X inherits implementation of foo from a class.
• in traits, warn on super[C] syntax where C is a superclass of this trait. Calling other super[mixin] is allowed unless it’s contradicts previous rule. Calling super[<empty>] is also allowed but means that runtime virtual dispatch would be used.

Depending on frequency of those warning we may decide not to implement the scheme 2 that I’ve proposed above, and instead simply reject the code that would require it.

[DarkDimius]

Two options:

1. Just before the phase ExpandPrivate move the original body to a method with a name mangled making it globally unique. Similar to how it is done by ExpandPrivate now. The very same phase will rewrite super calls to call those uniquely named methods.

   The major disadvantage would be increase in size of stack traces. AFAIK, unlike .NET, HotSpot does not expose a way to hide those entries from stack. I would also expect a minor increase in size of generated bytecode.

2. When compiling class containing super-call(C in your example) create a @static val that delegates to reflection in standard library to find the specific target. Compile the super-call itself to an invokeDynamic that evaluates to a ConstantCallSite that points to method that was found using reflection. This one can be benchmarked before implementing it in compiler.

   If this one works right and is fast, I would prefer it, as 90% of it can be implemented at library side and I’d prefer to start moving more such magic to library. This logic is complex, it will have bugs. If it is entirely implemented on library side, it can be fixed by a library bump without need for recompilation.