Return the "real" Symbol
instead of sometimes a Symbol
whose owner
is a subclass.
#4273
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.
Return the "real"
Symbol
instead of sometimes aSymbol
whoseowner
is a subclass.We accomplish this by calling
baseSymbol()
on the initialSymbol
.(We likely should do this in more places in Error Prone, including the location in
ASTHelpers.getSymbol
that I've flagged and perhaps anywhere else that we directly accesstree.sym
.)Thanks to @msridhar for links to relevant JDK discussions, notably JDK-8293890.
Effects:
ParameterNameTest
, which fails before this change. (I didn't actually look into why the test fails before. Maybe the "fake"Symbol
lacks the parameter names of the original?)someSerializable.equals
. It seems likely to, but shrug for now.TestCase.fail
handling inReturnMissingNullable
, but it turns out that I'm wrong on multiple levels. I updated its comments and tests accordingly:TestCase.fail
does exist as a declared method nowadays; it's not merely inherited fromAssert
. I must have been looking at quite an old version.ASTHelpers.getSymbol
to usebaseSymbol()
but instead for the need forMethodMatchState.ownerType
to look at the actualowner
instead of the type of the receiver tree. (If it started to do that, it would then benefit from this change to produce the correctowner
.) I added a link to the appropriate bug there.