Indicate users what specific rule gets triggered when running check or apply

[EricGao888]

• When we add replaceRegex with Spotless, it takes effect silently when running mvn spotless:apply. If we use mvn spotless:check, it will point out the specific line which violates the rule but will not tell which specific rule the code violates. If we could have the name of replaceRegex printed as well, it would help.
• For example, if we use the following configuration, and there are some wildcard imports in the code, it would be better if users could see some message like triggering Remove wildcard imports rule when running mvn spotless:apply or mvn spotless:check.

                        <replaceRegex>
                            <name>Remove wildcard imports</name>
                            <searchRegex>import\s+[^\*\s]+\*;(\r\n|\r|\n)</searchRegex>
                            <replacement>$1</replacement>
                        </replaceRegex>

Thanks!

[nedtwigg]

Firstly, it's important to note that Spotless is not a list of rules, it is a list of functions, String -> String, and that is all. There are lots of advantages to this model, like our idempotence guarantee. But one of the disadvantages is that it's hard to attribute a specific failure to a specific rule. But it is possible! Here is how we could do it.

1. First, identify which lines are different between the input content and the canonical formatted content.
2. Now, apply each step on the input content, one at a time.
   1. For each step, diff the before/after, and identify which lines were changed
   2. This is more complicated than it seems at first, because of the idempotence guarantee mentioned earlier, it might be the case that steps are applied more than once.
3. Now, for each line in the canonical content, you have list of which steps altered that line, which you can use to annotate the changes.

That's a big project, but it would be possible. My guess is that it's not worth the effort, but who knows what PR's might show up someday :)

[Marcono1234]

A workaround specifically for the wildcard import removal mentioned above could be to append a comment indicating that wildcard imports are disallowed and making the import invalid (see google/gson#2550):

-import·java.util.*;
+import·java.util.DISALLOWED.*;·//·wildcard·imports·are·not·allowed