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 #12542: new TreeWalker property to skip exceptions #14779
base: master
Are you sure you want to change the base?
Conversation
6b3557a
to
800073f
Compare
src/main/resources/com/puppycrawl/tools/checkstyle/messages.properties
Outdated
Show resolved
Hide resolved
I think the 2 failing CIs are related to 2 new suppressions of non-compilable files. These new suppressions do not exist on the master branch, so these two non-compilable files will still fail the CI. |
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.
item:
ci command https://app.circleci.com/pipelines/github/checkstyle/checkstyle/25089/workflows/538c9779-440e-4a6e-a9eb-1361989b4ead/jobs/570860?invite=true#step-103-2 , you can try to run it on your local. recheck what is missing at https://github.com/checkstyle/contribution/blob/a2f8b1575c42b9156fdcedabbb528296eb32e09a/checkstyle-tester/projects-to-test-on.properties#L7 please send PR to that repo. |
@romani PR is created here checkstyle/contribution#852. |
Merged, CIs are restarted |
800073f
to
55f4771
Compare
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:
55f4771
to
be6cfce
Compare
be6cfce
to
b95374d
Compare
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:
b95374d
to
c6a72a2
Compare
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.
Ok to merge.
Thanks a lot!
Sorry for didn't catch that |
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 don't see any regression provided to ensure this is working.
We need 2 reports. One with default treewalker (expecting no changes), another with new property turned on (show exceptions removed).
getFilteredViolations(file.getAbsolutePath(), contents, rootAST); | ||
addViolations(filteredViolations); | ||
catch (CheckstyleException ex) { | ||
if (!skipFileOnJavaParseException) { |
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.
This catch spans almost the entire method and has the possibility to catch more than just parsing exceptions. There is no check that we are catching parse exceptions. We could be catching much more.
This should be trimmed back to ensure it only catches parse exceptions.
There is issue #12803 to allow us to have more methods that throw checkstyle exceptions.
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.
@rnveach I agree, this is definitely not the best way to suppress expections. However, I was trying to only enclose final DetailAST rootAST = JavaParser.parse(contents);
with try-catch. But, in that case, I need to use a return
to block the following procedure, which will cause our CI to complain, since it is not allowed to have a return in a void method. Do you agree to suppress it?
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 agree to suppress yet. There should ways around this that follow our style rules.
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 can also add a local variable flag. When an exception occurs set the flag to true, and we guard the following procedure with this flag. If this flag is true, then we do not proceed the following procedure. What about this? I felt like this is somehow over-engineering and it is not very elegant, so that's why I didn't use this at the first try.
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.
Good catch, we should catch only parse exceptions, not CheckstyleException.
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.
We need to target with try catch only
catch (IllegalStateException ex) { |
So try catch should wrap only final DetailAST rootAST = JavaParser.parse(contents);
and we can catch CheckstyleException 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.
done, work around by using a skip
flag.
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.
@romani @rnveach This workaround using a skip
flag seems bring us more problems and potential suppressions with nullness.
checkstyle/src/main/java/com/puppycrawl/tools/checkstyle/TreeWalker.java
Lines 169 to 198 in e84dc9c
try { | |
rootAST = JavaParser.parse(contents); | |
} | |
catch (CheckstyleException ex) { | |
if (skipFileOnJavaParseException) { | |
skip = true; | |
} | |
else { | |
throw ex; | |
} | |
} | |
if (!skip) { | |
if (!ordinaryChecks.isEmpty()) { | |
walk(rootAST, contents, AstState.ORDINARY); | |
} | |
if (!commentChecks.isEmpty()) { | |
final DetailAST astWithComments = JavaParser.appendHiddenCommentNodes(rootAST); | |
walk(astWithComments, contents, AstState.WITH_COMMENTS); | |
} | |
if (filters.isEmpty()) { | |
addViolations(violations); | |
} | |
else { | |
final SortedSet<Violation> filteredViolations = | |
getFilteredViolations(file.getAbsolutePath(), contents, rootAST); | |
addViolations(filteredViolations); | |
} | |
violations.clear(); | |
} |
New surviving error(s) found:
<checkerFrameworkError unstable="false">
<fileName>src/main/java/com/puppycrawl/tools/checkstyle/TreeWalker.java</fileName>
<specifier>argument</specifier>
<message>incompatible argument for parameter ast of TreeWalker.walk.</message>
<lineContent>walk(rootAST, contents, AstState.ORDINARY);</lineContent>
<details>
found : @Initialized @Nullable DetailAST
required: @Initialized @NonNull DetailAST
</details>
</checkerFrameworkError>
<checkerFrameworkError unstable="false">
<fileName>src/main/java/com/puppycrawl/tools/checkstyle/TreeWalker.java</fileName>
<specifier>argument</specifier>
<message>incompatible argument for parameter root of JavaParser.appendHiddenCommentNodes.</message>
<lineContent>final DetailAST astWithComments = JavaParser.appendHiddenCommentNodes(rootAST);</lineContent>
<details>
found : @Initialized @Nullable DetailAST
required: @Initialized @NonNull DetailAST
</details>
</checkerFrameworkError>
<checkerFrameworkError unstable="false">
<fileName>src/main/java/com/puppycrawl/tools/checkstyle/TreeWalker.java</fileName>
<specifier>argument</specifier>
<message>incompatible argument for parameter rootAST of TreeWalker.getFilteredViolations.</message>
<lineContent>getFilteredViolations(file.getAbsolutePath(), contents, rootAST);</lineContent>
<details>
found : @Initialized @Nullable DetailAST
required: @Initialized @NonNull DetailAST
</details>
</checkerFrameworkError>
I felt like this structure of code is too complicated. This is the core code of the project, it would be hard for later maintainers if we do more workarounds In this case, do you prefer to still work on this workaround (add a dummy initial value for rooAST instead of null), or prefer to suppress a single return statement, or there are any better solutions. Please share your thoughts. I am out of ideas.
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.
it would be hard for later maintainers
If we want to have better code, please do this actively, right now this issue stuck in not done state, and users still having unfortunate decisions to disable checkstyle because it doesn't support modern language features.
You will not avoid catch of exception, so Checker will be not happy, and you will do just playing with creation of method that hide such exceptions handling, but conceptually all will stay the same.
If we start new method creation, you will stick in review more. My suggestion is pass review quicker, get feature out to users, and work in separate PR in beautiful code as much as we need, no rush. You can create new PR, right now and collaborate on ideal form of code.
There is no problem with mutation of variable, we do this in a lot of places, one day we will improve, but existence of this doesn't block users to receive bug fixes and new features.
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.
My suggestion is pass review quicker, get feature out to users, and work in separate PR in beautiful code as much as we need, no rush.
Thanks for your advice. I will aim to finish this PR right now by suppressing the checker shown above. :)
@romani In addition, is this something to enable for google/sun styles? What about our default regression configurations? |
@rnveach I was also thinking about this the other day. I think we can copy the original 2 check config files an make another 2 with this property on. I.e., we have 4 built-in config: 1. Sun 2. Google 3. Sun No Exception 4. Google No Exception. My reason is: there are users who want to use the original check with exceptions, and for other group of user, in their cases, they might want to ignore the exceptions. About our default regressions: |
I am against duplicating the configs. There is more work that goes into ensuring how they are built and we don't need the headache of maintaining 2 copies. |
No, we are not going to promote this property, user should use it only if they really want it, and they understand side effects.
I do not think we need this flag in our configs. We should clearly see exception in report. |
GitHub, generate report |
GitHub, generate report |
GitHub, generate report |
GitHub, generate report |
This is a mistake. I introduced Passing @Override
public void finishTree(DetailAST ast) {
if (ast == null) {
log(DEFAULT_LINE_NUMBER, MSG_KEY_NO_CODE);
}
} so it will be logged. Edit: based on observation locally, I think |
99701c6
to
07b5542
Compare
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.
Items
...le/com/puppycrawl/tools/checkstyle/treewalker/InputTreeWalkerSkipParsingExceptionConfig.java
Show resolved
Hide resolved
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.
Item:
src/test/java/com/puppycrawl/tools/checkstyle/TreeWalkerTest.java
Outdated
Show resolved
Hide resolved
07b5542
to
f15fbed
Compare
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.
ok to merge
GitHub, generate report |
@Lmh-java , please update config to make severity as IGNORE and generate one more report |
@Lmh-java , please extend tests to kill mutation https://github.com/checkstyle/checkstyle/actions/runs/9040829453/job/24845471896?pr=14779#step:7:24 You can reproduce it on your local by |
f15fbed
to
5885b6d
Compare
GitHub, generate report |
Done, waiting for the report |
Done |
Last update, please add this Checker stuff to suppression https://github.com/checkstyle/checkstyle/actions/runs/9052825433/job/24870931959?pr=14779#step:6:1707 |
5885b6d
to
ac0129b
Compare
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.
We could stand to improve this code in the future, but let's get this feature into user's hands first.
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.
Still reviewing the code.
Add an example to https://checkstyle.org/config.html#TreeWalker_Examples and explain when they would use such a feature and why. Be sure to explain we will only skip checks under TreeWalker and not under Checker.
@@ -539,6 +539,20 @@ | |||
<td><code>.java</code></td> | |||
<td>3.0</td> | |||
</tr> | |||
<tr> | |||
<td>javaParseExceptionSeverity</td> | |||
<td>Severity level to log Java parsing exceptions when they are skipped.</td> |
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.
=> Specify the severity level...
} | ||
|
||
/** | ||
* Sets severity level to log Java parsing exceptions when they are skipped. |
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.
=> Setter to specify the severity level...
Our default regression configuration ignores these exceptions. So it doesn't make sense we wouldn't add this. |
@Lmh-java Can you organize your regression reports? They seem a bit scattered. Also, the ones I am seeing only run against 1 project. We normally request for them to be run on all projects. This can impact more than just JDK 17 projects. If older projects show no differences, then it shows there is no harm. |
} | ||
if (filters.isEmpty()) { | ||
addViolations(violations); | ||
catch (CheckstyleException ex) { |
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.
This report shows we can get parse errors from more than just CheckstyleExceptions. It seems to me we need to expand it to all throwables for this to work properly.
Edit: We will also need a test case to show this. Let me know what the new test name will be.
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.
@Lmh-java , please add this file to our Inputs https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/diags/examples/VarargsAndReceiver.java without header comment.
@Lmh-java, please do us a favor Please send PR to remove this block |
Issue #12542
Diff Regression config: https://gist.githubusercontent.com/Lmh-java/3a5a8c875c81c4d71a5d19da3541fe2e/raw/8c46739f01519889daf23af48af3ce119c16a155/treewalker-base-config.xml
Diff Regression patch config: https://gist.githubusercontent.com/Lmh-java/6a86d78094428f7bf6aa01580cb5d0b7/raw/0e89015ce2c11c91698db7aaf0bdd05491992f1f/treewalker-patch-config.xml
Diff Regression projects: https://gist.githubusercontent.com/Lmh-java/53136c15cf1a376e3addeb00be0685a5/raw/40d234556e0371dc514df3b34e502de4f55993a6/treewalker-projects.properties