Add support to our Inputs for lines with multiple violations

[romani]

This was a problem for long time but become very acute at #13276 (comment)

We need to update our Abstract Test classes to allow lines like:

    Runnable noop = () ->{}; // 4 violations, see messages below 
                          // ''->' is not followed by whitespace'
                          // ''{' is not followed by whitespace'
                          // ''{' is not preceded with whitespace'
                          // ''}' is not preceded with whitespace'

so all messages are just on new lines below 4 violations, see messages below
So Reviewer will clearly see what is a violation.

example:

checkstyle/src/test/resources/com/puppycrawl/tools/checkstyle/checks/annotation/annotationlocation/InputAnnotationLocationIncorrect.java

Line 38 in 3d8ed42

@MyAnnotation1("foo") @MyAnn_21 void foo1() {} // 2 violations

but there are more in code.

pattern that used at PR, may be extra : is required to signal that second line is continuation:

    /**
     *  <p> <li> <TR> <Td> <tH> <.....
     *      <tFoot> // ok
     * @param field5 </p> value to which {@link #field5} is to be set to
     */
    // 4 violations 4 lines above:
    //                            'Unclosed HTML tag found: p'
    //                            'tag P_TAG_START'
    //                            'tag LI_TAG_START'
    //                            'tag BODY_TAG_START'
    private void setField5(int field5) {this.field5 = field5;}

As we process lines one by one, of we detect multiple-line pattern we look ahead for defined set of lines. Processing of such lines with violation only will not match any pattern so they will be skipped by general iteration over lines. Location of single quoted message can be at any indentation, to let user user any formatting to show message as he wants.

[romani]

@jxr98 , can you help us with this issue ?

[jxr98]

Thanks. I would love to help with this issue.

[romani]

@jxr98 , design is not set in stone, so your suggestion to change it to get more robust implementation is appreciated.
All we need is some form of explicit and visial definition of expected violation messages.

[jxr98]

Gotcha. Thanks for clarifying.

[jxr98]

The multiple violations in one line now are specified in comments as below

for (int i = 1; i > 1; i++) {} // 2 violations
                               // 'no space after '{', no space before '}''

As Romani pointed out, we can change to the example below

for (int i = 1; i > 1; i++) {} // 2 violations, list on separate lines below
                               // 'no space after '{''
                               // 'no space before '}''

The differences between multiple violations on one line and single violation on one line:

1. There're no numbers before the word violation in single violation. (multiple violations use the plural form)
2. Multiple violations are followed by newlines.

We can use these two differences to distinguish multiple violations and single violation. Each line followed by the plural form(violations) will be regared as a violation, and the verifyWithInlineConfigParser function will need to check if the specified number match the number of newlines as well.
Plz leave a message if you have any idea and correct me if I'm wrong. Thanks.

[nrmancuso]

What if we do:

    /*  4 violations below:
      ''->' is not followed by whitespace'
      ''{' is not followed by whitespace'
      ''{' is not preceded with whitespace'
      ''}' is not preceded with whitespace'
    */
    Runnable noop = () ->{};

and

    Runnable noop = () ->{};
    /*  4 violations above:
      ''->' is not followed by whitespace'
      ''{' is not followed by whitespace'
      ''{' is not preceded with whitespace'
      ''}' is not preceded with whitespace'
    */

?

I find this easier to read (less noise than single line comments and no comments on the lines with the code), and probably easier to parse since we have two ways to check for end of violation list (number of violations/lines in first comment line + block comment end delimiter).

[romani]

I like both variants, if we need to choose I would use what is easier to implement now to have this feature sooner.
Author of implementation should choose a way to make it.

[jxr98]

From implementation perspective, I need to look into details before deciding which one is easier to implement. I will try both variants a bit.

[romani]

Reopened for:

NOT done validation of messages for:

public class InputAbstractJavadocNonTightHtmlTags2 {
    /** <p> <p> paraception </p> </p> */
    // 3 violations above
    //                    'Unclosed HTML tag found: p'
    //                    'tag P_TAG_START'
    //                    'tag P_TAG_START'

I think it is better to do this after this PR, to make sure prove of concept is megred and second PR will be easy to accept as it will just extension.

[nrmancuso]

Completed via #14156