Correctly parse and unparse annotated wildcard types #214
Conversation
This file contains 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
Note that this does not mean that the wildcard annotations show up when compiled. I've had little luck with getting janino to produce signatures in the class bytecode in the first place. Hence the tests relevant to this commit are only constrained to the Unparser while the larger compile tests were left alone. The fact that wildcard tpyes can be annotated is not really well defined within the JLS: The only definition of this behaviour can be found in JLS8, 4.5.1 within the syntax of wildcards, which is then repeated in JLS8 section 18. But there is otherwise no supporting evidence. Outside the JLS, JVMS8, section 4.7.20.2 lists a few examples on where annotations appear, one of which is our wildcard annotation. It also seems to define that annotations which are on the right hand of a wildcard have a type_path_kind value of 2. Those on the left hand are not directly associated with the wildcard and have a type_path_kind value of 3 (as they referr to the type represented by the wildcard, not the bounds)
|
Lovely, comes even with a test case! Thanks for your contribution. |
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.
Note that this does not mean that the wildcard annotations show up when compiled. I've had little luck with getting janino to produce signatures in the class bytecode in the first place. Hence the tests relevant to this PR are only constrained to the Unparser while the larger compile tests were left alone.
The fact that wildcard tpyes can be annotated is not really well defined within the JLS: The only definition of this behaviour can be found in JLS8, 4.5.1 within the syntax of wildcards, which is then repeated in JLS8 section 18. But there is otherwise no supporting evidence. Outside the JLS, JVMS8, section 4.7.20.2 lists a few examples on where annotations appear, one of which is our wildcard annotation. It also seems to define that annotations which are on the right hand of a wildcard have a type_path_kind value of 2. Those on the left hand (which this PR implements) are not directly associated with the wildcard and have a type_path_kind value of 3 (as they referr to the type represented by the wildcard, not the bounds)
Note that local variable declarations seem to not support annotated types, this PR does not touch those and as such annotating the type arguments for them still continues to fail - with and without wildcards.
Also, I am aware that the Unparser test contains code that shouldn't compile, but I expect this to not be a concern since the code will never get compiled anyways. Should my expectation be false, please do notify me about that however.