RFR: 8345263: Make sure that lint categories are used correctly when logging lint warnings [v2]

[Maurizio Cimadamore]

On Fri, 6 Dec 2024 10:27:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> But perhaps then we should then consider lambda-ification, which would simplify this down to:
>>> 
>>> ```java
>>> lint.check(log, pos, LintWarnings.FooProblem,
>>>   () -> complicatedCalculationA() && complicatedCalculationB());
>>> ```
>> 
>> I thought about this as well but found it a bit too convoluted for my liking. One might already argue that `Lint::logIfEnabled` is doing two things at once (check and log). Making it an open box where you check if the lint is enabled, you check some user provided condition, and if both are true then you log" seems a rather ad-hoc API to add :-)
>
> Overall I just think the problem of "you checked for A, but are logging a B" is not big enough to warrant an hammer like this.

What would be better, IMHO, is to investigate an automate way to e.g. enhance something like CheckExamples to automatically test for suppression of lint warnings. E.g. for each diagnostic example that refers to a lint warning, it would be great if we could run the example with `-Xlint:-xyz` (to test command-line suppression) and maybe to auto-decorate the whole thing with `@SuppressWarnings("xyz")` and try again (to test programmatic supression) -- where `xyz` is the lint category associated to the compiler key under test. While this is probably too big to tacked as part of this PR, I don't see why we couldn't automate part of this -- and this will ensure that any issue where suppression is not respected is identified early in the process.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1873062627