-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
False positive on equals(nullable) when using NullAway with Java 21. #897
Comments
I've reproduced this bug, thanks for reporting it! It's a strange one. I'll work on a fix. |
This is due to the fix for https://bugs.openjdk.org/browse/JDK-8272564 landing in JDK 18. Further discussion of technical details here: https://bugs.openjdk.org/browse/JDK-8272715. I'll continue working on a fix here; I think we'll need to somehow special case implicit methods in interfaces that come from |
Thank you for the quick turnaround @msridhar! Much appreciated! |
Sure thing, we will try to get this landed soon. Once it lands would it be helpful to you if we cut a release with the change? |
(I'm wondering if we can fix this on the Error Prone side inside |
Fixes #897 This fixes a regression in our handling of implicit `equals()` methods in interfaces when building on JDK 21. I see this as an interim fix, until we can fix NullAway to properly always assume / enforce that the parameter of `equals()` is `@Nullable`. But, I think we should fix the regression in the short term.
Once again thank you so much for the quick turnaround!
@msridhar extremely so! 😁 Right now, as a workaround we are forced to use |
@vrasidas-at-b2c2 New release cut, please wait a few hours for it to be propagated :) |
…er` is a subclass. We accomplish this by calling `baseSymbol()` on the initial `Symbol`. (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 access `tree.sym`.) Thanks to @msridhar for links to relevant JDK discussions, notably [JDK-8293890](https://bugs.openjdk.org/browse/JDK-8293890). Effects: - This change definitely helps with [static imports](uber/NullAway#764), as demonstrated in a new test in `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?) - I didn't check whether it helps with [`someSerializable.equals`](uber/NullAway#897). It seems likely to, but _shrug_ for now. - I had expected this to help with the `TestCase.fail` handling in `ReturnMissingNullable`, 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 from `Assert`. I must have been looking at [quite an old version](junit-team/junit4@dde798f#diff-f9834c0e0ef1d54e1757e221b7b4248c2ba8e0de41d2f0fadac5927b906edd85R226). - The problem there comes not from the need for `ASTHelpers.getSymbol` to use `baseSymbol()` but instead for the need for `MethodMatchState.ownerType` to look at the actual `owner` instead of the type of the receiver tree. (If it started to do that, it would then benefit from this change to produce the correct `owner`.) I added a link to the appropriate bug there. PiperOrigin-RevId: 601163959
…er` is a subclass. We accomplish this by calling `baseSymbol()` on the initial `Symbol`. (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 access `tree.sym`.) Thanks to @msridhar for links to relevant JDK discussions, notably [JDK-8293890](https://bugs.openjdk.org/browse/JDK-8293890). Effects: - This change definitely helps with [static imports](uber/NullAway#764), as demonstrated in a new test in `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?) - I didn't check whether it helps with [`someSerializable.equals`](uber/NullAway#897). It seems likely to, but _shrug_ for now. - I had expected this to help with the `TestCase.fail` handling in `ReturnMissingNullable`, 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 from `Assert`. I must have been looking at [quite an old version](junit-team/junit4@dde798f#diff-f9834c0e0ef1d54e1757e221b7b4248c2ba8e0de41d2f0fadac5927b906edd85R226). - The problem there comes not from the need for `ASTHelpers.getSymbol` to use `baseSymbol()` but instead for the need for `MethodMatchState.ownerType` to look at the actual `owner` instead of the type of the receiver tree. (If it started to do that, it would then benefit from this change to produce the correct `owner`.) I added a link to the appropriate bug there. PiperOrigin-RevId: 603374262
It's possible that google/error-prone@e5a6d0d (which will be in the next Error Prone release) will eliminate the need for a NullAway workaround. However:
|
Thanks @cpovirk! Yes we will need to keep our workaround until we decide to require the next Error Prone release from all users. But I can try to remember to add a comment once the next release comes out so we remember to remove our workaround eventually :-) |
We are attempting to migrate our codebase from Java 17 to 21. We have run into a peculiar issue where NullAway started producing false positives when calling on
equals()
with a nullable parameter. This did not use to be the case.NullAway version:
0.10.19
and0.10.21
Repro:
The above when built with Java 21 (
OpenJDK 64-Bit Server VM Zulu21.28+85-CA (build 21+35, mixed mode, sharing)
results in error:When built with Java 17 (
OpenJDK 64-Bit Server VM Zulu17.32+13-CA (build 17.0.2+8-LTS, mixed mode, sharing)
) no error is generated.
The text was updated successfully, but these errors were encountered: