Fix ParamForwarder under non-separate compilation #2116
Conversation
The test intent is to check that ParamForwarder optimises away the fields in SubA and B, but even if ParamForwarder fails to do that, Constructors will do it if the accessor is only used in the constructor, adding a method that calls the accessor is needed to make sure this does not happen.
`inheritedAccessor` looks for a method in a superclass whose name matches the param accessor name, but that method is created by ParamForwarder itself, so this only succeeded under separate compilation (as demonstrated by the existing `paramForwarding_separate` test). We fix this by simply running `inheritedAccessor` at a phase where `ParamForwarder` has already been run.
| class B(member: Int) extends SubA(member) { | ||
| def getBMember = member | ||
| } | ||
|
|
There was a problem hiding this comment.
I am not yet convinced this fixes it. Can you also add test cases where A, SubA, and B appear in different orders? Like: B, SubA, A, for instance?
There was a problem hiding this comment.
You mean, order of declaration in the file?
|
@odersky Ah, you're right, changing the order of declaration breaks things, I guess that makes sense since |
We cannot rely on ParamForwarder having been run on the superclass even if we're in the correct phase since ParamForwarder is not a mini-phase. Instead, we should accept a candidate even if it's not a method. This fixes `tests/run/paramForwarding_together_b.scala`, this also required updating `tests/run/paramForwarding.scala` since the field in `Y` is not actually required.
smarter
force-pushed
the
fix/param-forwarder-nonsep
branch
from
ffe59ef to
18cc128
Compare
|
We're getting pickling differences like this: --- compiler/before-pickling.txt 2017-03-17 17:42:45.365222146 +0100
+++ compiler/after-pickling.txt 2017-03-17 17:42:45.369222105 +0100
@@ -5985,7 +5985,7 @@
private[this] def statement: dotty.tools.dotc.ast.untpd.ValDef =
<
<
- <<super:Request.this.ValOrPatHandler(ValHandler.super)>@<27630..27630>.statement:
+ <<super:Request.this.ValOrPatHandler(ValHandler.super)>@<27630..27630>.statement:=>
dotty.tools.dotc.ast.untpd.Tree
>@<27630..27630>
.asInstanceOf:([X0] => X0)>@<27630..27630>I suspect that what's happening is that we're selecting the |
|
Superceded by #2124 |
inheritedAccessorlooks for a method in a superclass whose namematches the param accessor name, but that method is created by
ParamForwarder itself, so this only succeeded under separate
compilation (as demonstrated by the existing
paramForwarding_separatetest). We fix this by simply running
inheritedAccessorat a phasewhere
ParamForwarderhas already been run.