Javaparser #183
Javaparser #183
Conversation
| val vparams = formalParams() | ||
| if (!isVoid) rtpt = optArrayBrackets(rtpt) | ||
| optThrows() | ||
| val bodyOk = !inInterface || (mods is Flags.DefaultMethod) |
There was a problem hiding this comment.
Looks like you didn't pick up scala/scala@17a1abb.
It would be really helpful to record the SHA of scala/scala from which you ported this, so that in the future merging is possible. It would also be great to discuss if this is a straight port, if if you had to make any interesting changes to fit into dotc.
There was a problem hiding this comment.
I ported from scala/scala@9753f23, which was before scala/scala@17a1abb.
I have updated the first commit message with the SHA and some discussion of the changes from scalac. Only very minor changes were needed.
|
for t1751 and t294 types in tree are correct(and thus were correctly tranformed). |
olhotak
force-pushed
the
javaparser
branch
2 times, most recently
from
7866919 to
8e28653
Compare
|
I tried cherry-picking 1b79def from #184, but it did not fix t1751 and t294. I investigated the behaviour of elimrepeated in the debugger. It appears that it does actually eliminate repeated parameters correctly, even though they are inside an annotation tree. However, after the method type with eliminated parameters has been created, it gets thrown out by a call to cur.current in Denotations.scala. Could this be an issue with the lifetime of the transformed method info? I think I will need help in person to debug this. |
Ported from scalac 2.11.x branch SHA 9753f23f9362b25a9f481b11dd8d51187187882a This is mostly a direct port, with few significant dotty-specific changes needed. The two more significant changes are: In dotty, the first constructor of a class is pulled out separately from the other stats in the Template. The keyword detection code (buildKeywordArray) was moved into Tokens so that it can more cleanly be shared by the Scala and Java scanners.
A Java constructor needs to see the import of the companion object of the class. It is not necessary to move to an outer context because a Java constructor does not have an implementation. scalac also does it this way: see Namers.Namer.createNamer.isConstrParam.
The dummy constructor is needed so that the real constructors see the import of the companion object. The constructor has a parameter of type Unit so that no Java code can call it.
transformSym explicitly checks that a field is JavaDefined and does not create a symbol for it. Creation of a setter body looks for the symbol and fails because it does not find it. We do not need setter bodies for Java fields because we are not generating bytecode for them.
|
I have rebased to dotty master and fixed most of the resulting issues. I have fixed the problem with Java constructors not seeing the import of the companion object. The two elimrepeated tests are still failing. Newly failing is t1782. It contains a NamedArg in an annotation declaration. FirstTransform does not transform it because it is in an annotation, then fails an assertion because the NamedArg still exists. |
Backport "Undo patch of double-block apply" to 3.3 LTS
Java parser for dotty.
As we discussed, three tests are still failing:
Requires import of companion object before first constructor.
Tree transformer does not transform repeated method arguments within an annotation instantiation.
Review by @odersky @DarkDimius