Javaparser & ElimRepeated fixes & Annotation-fixes #213
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
DarkDimius
force-pushed
the
javaparser
branch
from
f2bc17d to
3975fce
Compare
|
@odersky @olhotak All tests that were failing previously now succeed, but we have several new failing tests that were previously succeeding, but now fail due to new phases not able to work on java-defined trees: 2 tests have a call from scala to java-defined method with repeated arguments that doesn't retypecheck after elim-repeated.(either typer should use JavaSeqLiteral in such cases or ElimRepeated should adapt trees). And there's one test disabled due to breaking of owner chains. I propose to merge this as we want all phases to be tested also on java and fix those small errors in different PR. |
DarkDimius
changed the title
|
When I had similar problems on other tests, @odersky suggested that we should drop all trees of all Java compilation units immediately after FrontEnd. |
Closed
|
See comments on commits. I would recommend to parse array arguments to Java annotations as JavaSeqLiterals. |
DarkDimius
force-pushed
the
javaparser
branch
from
7e1b2ea to
46c9ffa
Compare
Helps to track where erroneous type was created.
This doesn't require additional argument. Decision can be made solely from the phaseId.
See scala#209 for explanation.
Check now fails after erasure. Should become error after fixed.
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.
to be reused by FirstTransform
Required as gettersAndSetters ignores modifiers in tree and uses ones in the type instead. This means that gettersAndSetters carries over modifiers from type to tree and this one violates postconditions.
Annotations in java could be compiled as-if array-only annotation had <repeated> arguments constructor. That isn't true for scala. Also, type checking creation of single-element array requires implicit resolution to provide ClassTag. This makes problems while reading deferred annotation.
see annot.scala for examples
Packages also get a JavaDefined flag, but they shouldn't be removed by FirstTransform.
DarkDimius
force-pushed
the
javaparser
branch
from
46c9ffa to
859a7fe
Compare
DarkDimius
added a commit
that referenced
this pull request
Nov 24, 2014
Javaparser & ElimRepeated fixes & Annotation-fixes
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This branch includes everything in #184 #183 and #206
And additionally fixes several annotation-related errors.
Last commit rises two problems with reading annotations from java and java bytecode.
Java treats annotations which have array-value (eg
java.lang.annotation.Target) as also having a repeated-argument constructor. Potential workaround could be to synthesize one more constructor for annotations.The second problems comes from scala not having specific single-argument
applyinsideArray$. This means that callingArray("hi")goes through generic path and requires implicit resolution to provide a ClassTag.This means that deferring reading annotations after
frontendrequires calling them with context at phase frontend. Which itself leads to errors as implicit resolution will start flowing Context owner chain and will see a non-perioded context as direct ancestor of current one.