| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Recovered and adapted some test cases for super calls from #5415
|
| |
|
|
|
|
|
|
|
|
| |
Also eliminates the warning when a mixin forwarder cannot be implemented
because the target method is a java-defined default method in an
interface that is not a direct parent of the class.
The test t5148 is moved to neg, as expected: It was moved to pos when
disabling mixin forwarders in 33e7106. Same for the changed error
message in t4749.
|
| |
|
|
|
|
|
|
| |
Super calls to indirect java parent interfaces cannot be emitted, an
error message is emitted during SuperAccessors.
The error message was missing if the super call was non-qualified,
resulting in an assertion failure in the backend.
|
| |
|
|
|
|
|
|
| |
The restriction for super calls to methods defined in indirect super
classes introduced in a980fde was over-restrictive. In particular, it
ruled out a valid code pattern to select a method from a superclass
when an unqualified `super` would resolve to an override defined in a
trait (example in the commit as a test).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a call super[T].m resolves to a method A.m where A is a class, but
not the direct superclass of the current class, there is no way to
emit an invocation of A.m: `invokespecial A.m` will resolve to B.m
where B is the superclass of the current class.
This commit adds an error message in this case.
Note that this is similar to an existing error message for qualified
super calls to a non-direct superclass:
class A { def m = 1 }
class B extends A { override def m = 2 }
class C extends B { override def m = super[A].m }
Gives "error: A does not name a parent class of class C".
If the user means to call method m in the superclass, he can write an
unqualified `super.m`.
An similar error message is introduced if A is a Java-defined interface
(and m is a default method), and A is not a direct parent of the current
class. In this case `invokespecial A.m` is invalid bytecode. The
solution is to add A as a direct parent of the current class.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With -Xgen-mixin-forwarders the compiler eagerly creates mixin
forwarders for methods inherited from traits, even if the JVM method
resolution would pick the correct default method.
When generating a such a forwarder for a Java-defined default method,
the mixin forwarder invokes the default method directly using
`invokespecial` (for Scala-defined trait methods, the forwarder uses
the static `m$` method that is generated for every trait method).
An `invokespecial` call is only legal if the named interface is a
direct parent of the current class. If this is not the case, we don't
generate the mixin forwarder and emit a warning.
In the tests there's also an example where a mixin forwarder is
required for correctness, but cannot be added because the corresponding
`invokespecial` call would be invalid. In this case we emit an error.
This is similar to what we already do for other super calls to Java-
defined default methods. The difference is that the super call is not
written by the user but generated by the mixin forwarder. The solution
is the same: add the interface as a direct parent.
|
| |
|
|
|
| |
Introduce a compiler option -Xgen-mixin-forwarders to always generate
mixin forwarder methods.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And use this as the target of the default methods or
statically resolved super or $init calls.
The call-site change is predicated on `-Yuse-trait-statics`
as a stepping stone for experimentation / bootstrapping.
I have performed this transformation in the backend,
rather than trying to reflect this in the view from
Scala symbols + ASTs.
We also need to add an restriction related to invokespecial to Java
parents: to support a super call to one of these to implement a
super accessor, the interface must be listed as a direct parent
of the class.
The static method names has a trailing $ added to avoid duplicate
name and signature errors in classfiles.
|
| |
|
