-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Issue # 11187: OperatorWrapCheck throws NPE on guarded patterns #11188
Conversation
5e9d5ab
to
acb73d8
Compare
acb73d8
to
184b5bf
Compare
Github, generate report |
184b5bf
to
f0e1eca
Compare
f0e1eca
to
d8ecba2
Compare
CI failure is not related: |
d8ecba2
to
5a4e2e3
Compare
private static boolean isInPatternDefinition(DetailAST node) { | ||
DetailAST parent = node.getParent(); | ||
while (parent != null && parent.getType() != TokenTypes.PATTERN_DEF) { | ||
parent = parent.getParent(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not?
DetailAST parent = node;
do {
parent = parent.getParent();
} while (parent != null && parent.getType() != TokenTypes.PATTERN_DEF);
Also we are passing through parents uncontrolled. It doesn't matter if we pass any other kind of def before hitting the pattern def?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not...
Please explain the advantage of this; to me the name of variable declared (parent
) and initialization (node.getParent();
) makes sense. Since we are checking operands, there is absolutely no chance that node
is null (it will always have an operator as a parent).
It doesn't matter if we pass any other kind of def before hitting the pattern def?
To the check, no.And a local variable (pattern definition) will always have an enclosing block of some sort, so we certainly could just check for a method definition, etc., and stop there. But, I generally avoid this sort of "optimization" since pitest normally fails on this sort of thing, unless we also remove the null check.
On second thought, I might be able to create a case to make this fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not know why, but my brain not always work quick on do-while structure. I prefer while loop in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a big deal in this case, but I see the duplication of getParent
and possibly an extra unnecessary condition check at the start of the loop and I think how to optimize it more. Hence the do-while version. If getParent
was more complex or more method calls on the line, then it would be a better sell.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, I might be able to create a case to make this fail.
I am assuming this item is still TODO until told otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I saw the update, but I am still not really seeing a conclusion to this item:
It doesn't matter if we pass any other kind of def before hitting the pattern def?
For example, it doesn't matter if we pass through an anonymous class to get to the pattern def or patterns are such that we are either in it or not for what we stop on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
anonymous class to get to the pattern def
It is not possible to declare an anonymous class within a pattern definition.
patterns are such that we are either in it or not for what we stop on.
Please restate this, I am not sure that I understand what you are asking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reminder. This is fix for exception, it should merged sooner. If we think there is some false positive on code that we can not imagine easily, it is better to address in separate issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will approve the PR, but we have seen cases before where we either go too deep in the tree or go past too many key nodes when looking for "something" and we are accidentally pulling in nodes wrongly or passing things that should have stopped us. branchContains
is one good example. #5124 (comment) details the specifics of how it was going to far and wasn't be used carefully enough.
Whenever I see a loop where we are scanning up or down uncontrolled, I get concerned. I don't know the new Java syntax well, so I can't explain a possible situation to prompt a more meaningful conversation. I am just making sure this won't be an issue later and we are truly good with the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Condition is updated to exit loop ASAP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
last commit is ok to merge
95a9a25
to
586d278
Compare
Github, generate report |
586d278
to
164a257
Compare
164a257
to
aef37bf
Compare
Github, generate report |
aef37bf
to
f3b5724
Compare
f3b5724
to
44335b5
Compare
Github, generate report |
Github, rebase |
44335b5
to
e54fd18
Compare
Regression , NPE is detected by CI. |
e54fd18
to
c4775e0
Compare
Github, generate report |
c4775e0
to
3297c07
Compare
Github, generate report |
3297c07
to
62e5eeb
Compare
Closes #11187
Diff Regression config: https://gist.githubusercontent.com/nmancus1/284f66dbf5a076b43708b7685ee9bd53/raw/c595fc26ae622509dadcd25ca6fe02b3db5ffaac/config.xml
Diff Regression projects: https://raw.githubusercontent.com/checkstyle/contribution/e34312d61da0b073f31339cfbf385f289b721fed/checkstyle-tester/projects-to-test-on-for-github-action.properties
Final report: https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/586d278_2022024156/reports/diff/index.html
No diffs now that #10848 is closed.