Fix modelling of array types for annotation processing #294
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
![copybara-service[bot]](https://avatars.githubusercontent.com/in/44061?s=60&v=4){kind=small}
copybara-service
bot
force-pushed
the
test_main_578196080
branch
from
87e572c
to
d9df221
Compare
copybara-service
bot
force-pushed
the
test_main_578196080
branch
from
d9df221
to
a1c7f7e
Compare
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.
Fix modelling of array types for annotation processing
A
@C int @A [] @B []is an '@Aarray of@Barrays of@C ints'. Turbine was parsing that example as(ArrayType @B (ArrayType @A (PrimitiveType @C int))), and then reversing the list of element types to compute the type path for the annotations in the output, and producing correct class files. The difference was still visible to the annotation processing API, and the wrong type annotations were showing up onArrayType#getComponentTypefor multi-dimensional arrays.This change fixes the bug by parsing the above example as
(ArrayType @A (ArrayType @B (PrimitiveType @C int))). This requires reversing the list when pretty-printing the AST node, but simplifies computation of type_paths, and makes the right annotations show up onArrayType#getComponentType.This also simplifies parsing logic, the handling of trailing 'c-style' dimension
specifiers can now be handled by the same logic that parses regular dimension
specifiers.
Some combinations of multi-variable declarations and c-style arrays still
disagree with javac, which has known bugs in that area.
Finally, the integration test being added here for type annotations and
annotation processing will be generalized to also exercise type annotations
read from bytecode, to test the fix for b/307310010.