-
Notifications
You must be signed in to change notification settings - Fork 744
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 positives for OperatorPrecedence bug pattern #4153
Comments
The change to OperatorPrecedence was 39d2884 Can you say more about why this is a false positive for you? The suggest change is behaviour-preserving. The intent is that it makes it easier to read, which is of course subjective, the Google style guide suggest adding parens unless "there is no reasonable chance the code will be misinterpreted without them". |
Thanks for the pointer, makes sense to me. May be worth extending the documentation, after 39d2884 and also mention ternary operator in addition: [1]? Suggestion:
WDYT? [1] https://docs.oracle.com/javase/tutorial/java/nutsandbolts/operators.html |
Updating the docs SG. I wonder about just providing some code examples, instead of trying to use prose to describe the cases it supports (or committing to which exact examples it will suggest parens for). What do you think about something like
|
#4153 PiperOrigin-RevId: 574878098
#4153 PiperOrigin-RevId: 574883084
We are trying to migrate to the latest rules_java 7.0.6 version in Bazel, and seeing this 4 false positive breakages: [1].
The common pattern seems to be logical condition combined with ternary operator:
that error prone suggesting to change like this:
or:
that error prone suggesting to change like this:
To reproduce, clone Gerrit Code Review recursively with this CL applied: [2], and run:
$> bazel build java/com/google/gerrit/server/...
[1] https://gerrit-review.googlesource.com/c/gerrit/+/390116
[2] https://gerrit-review.googlesource.com/c/gerrit/+/387360
The text was updated successfully, but these errors were encountered: