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
Indentation: Unexpected violation when class declaration is wrapped after public and before static #14716
Comments
This comment was marked as outdated.
This comment was marked as outdated.
Expected output says to remove line 12, which is
I disagree with this issue, specifically the words |
@rnveach Updated the title and also added explanation. If there is still a disagreement. Let's consult with @nrmancuso, and know his opinion as well. |
Few things here:
|
I fixed issue title and description. Top levle problem is approved. All details on clases and all types of modifies and annotations we will discuss in pull request. |
Hm, still looks like we don't understand the problem here. Before any work starts on this issue, we should clearly understand the problem, and make sure we are on the same page about the expected behavior of this check. It looks like indentation check cannot properly handle any wrapped modifiers in a class definition at all (or maybe only one??), so the current examples and issue description really don't demonstrate the "high level problem" or give me confidence that we understand and agree on the expected check behavior. |
@nrmancuso - On a high level - as per my view: the problem is, we cannot treat the modifiers 2nd perspective: Our code has 2 levels of indentation check.
Now, I am not sure why this kind of hierarchy was actually made in the code? - in my opinion there should have been only one handler for certifying the indentation of any line. Anyways - I am raising a PR. Feel free to suggest additional inputs for the test case file. |
Why? Why should some modifiers be indented differently than others?
I am not interested in reviewing PRs until it is clear what the actual problem we are trying to solve is.
None of this is important to making the problem with indentation checks behavior clear. |
Can't treat them equally when they are wrapped. Since doing so will enforce wrong indentations to them when they are wrapped in class def. If If it occurs at start of line then indentation check by ClassDefHandler is correct! Hence unequal treatment depending on whether wrapped or not! |
Bottom line: all and any modifiers on a class definition should be treated identically (aside from annotations possibly); if they are in a line wrapped class definition, the second and all subsequent lines should have the correct line wrapping indentation. I don’t know why we keep coming back to certain modifiers. Does this check treat different modifiers differently? |
See my code changes and test input file. |
@nrmancuso - See this regression report. |
Hi. @rnveach @nrmancuso. I have written a number of wrapping scenarios and audited them with checkstyle. Config.xml <?xml version="1.0"?>
<!DOCTYPE module PUBLIC
"-//Checkstyle//DTD Checkstyle Configuration 1.3//EN"
"https://checkstyle.org/dtds/configuration_1_3.dtd">
<module name="Checker">
<property name="tabWidth" value="4"/>
<property name="charset" value="UTF-8"/>
<property name="severity" value="warning"/>
<property name="fileExtensions" value="java, properties, xml"/>
<module name="TreeWalker">
<module name="Indentation">
<property name="tabWidth" value="4"/>
<property name="basicOffset" value="2"/>
<property name="braceAdjustment" value="2"/>
<property name="caseIndent" value="2"/>
<property name="throwsIndent" value="2"/>
<property name="lineWrappingIndentation" value="4"/>
<property name="arrayInitIndent" value="2"/>
</module>
</module>
</module> public class InputIndentationClassDeclarationWrapped {
public class NoWrap {};
public
static class WrapBeforeStatic {};
public static
class WrapAfterStatic {};
public static
final class WrapAfterStaticAndBeforeFinal {};
public
static
final class WrapBeforeStaticAndBeforeFinal {};
public
static
final
class WrapBeforeStaticAndAfterFinal {};
public @X class NoWrapWithAnnotation {};
public @X @Y @Z class NoWrapWithManyAnnotations {};
public
@X @Y @Z class ManyAnnotationsWrapped {};
public @X
@Y @Z class OneWrapWithManyAnnotations {};
public @X
@Y
@Z class ManyAnnotationsWithManyWraps {};
public static @X @Y final class NoWrap2 {};
public static
@X @Y final class WrapBetweenStaticAndAnnotation {};
public static @X @Y
final class WrapBetweenAnnotationAndFinal {};
public static @X
@Y final
class ManyWrap2 {};
public
static @X @Y
final class ManyWraps3 {};
@interface X {};
@interface Y {};
@interface Z {};
} Audit Report - master br. kalpadiptya@Kalpadiptya:~/work/checkstyle$ java -jar target/checkstyle-10.15.0-SNAPSHOT-all.jar -c config.xml InputIndentationClassDeclarationWrapped.java
Starting audit...
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:5:7: 'class def modifier' has incorrect indentation level 6, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:11:7: 'class def modifier' has incorrect indentation level 6, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:14:7: 'class def modifier' has incorrect indentation level 6, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:15:11: 'class def modifier' has incorrect indentation level 10, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:18:7: 'class def modifier' has incorrect indentation level 6, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:19:11: 'class def modifier' has incorrect indentation level 10, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:27:7: 'class def modifier' has incorrect indentation level 6, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:30:7: 'class def modifier' has incorrect indentation level 6, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:33:7: 'class def modifier' has incorrect indentation level 6, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:34:9: 'class def modifier' has incorrect indentation level 8, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:39:7: 'class def modifier' has incorrect indentation level 6, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:42:7: 'class def modifier' has incorrect indentation level 6, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:45:7: 'class def modifier' has incorrect indentation level 6, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:49:7: 'class def modifier' has incorrect indentation level 6, expected level should be 2. [Indentation]
[WARN] /home/kalpadiptya/work/checkstyle/InputIndentationClassDeclarationWrapped.java:50:11: 'class def modifier' has incorrect indentation level 10, expected level should be 2. [Indentation]
Audit done. |
If config is set correctly, the java code looks formatted fine, so no violations. @nrmancuso 's concern is all modifiers get equal treatment, not what correct formatting looks like. |
@rnveach - Hmm. I see. Lines 493 to 508 in e30260d
And interestingly this function is emitting violations. which as per How should we deal with |
Detected at #14149 (comment)
Expected: no violations
Sample Input:
Sample Config:
Output:
Possibly Desired/Expected Output: (need to be clarified during imlementaion)
Observation: During IndentationCheck, any Class Definition is first scanned by ClassDefHandler, where it does a primitive indentation check. Post that, LineWrappingHandler gets the responsibility for further indentation check.
Now, Line 12 is a case where LineWrappingHandler's decision should prevail, whereas in present case ClassDefHandler's decision is prevailing.
Intuition: If we encounter a Token like ANNOTATION / STATIC / STRICTR within a class def., then ClassDefHandler should not decide on its indentation if this token is preceded by modifiers like PUBLIC / ABSTRACT/ FINAL, so that LineWrappingHandler gets the liberty to do so.
The text was updated successfully, but these errors were encountered: