RFR: 8344079: Minor fixes and cleanups to compiler lint-related code [v2]

[Archie Cobbs]

On Tue, 3 Dec 2024 16:04:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> In terms of user experience, what would be the difference between using `log(LintWarning)` and `log(Warning)` ? I believe there is a need for having a method that "just logs" because sometimes (see my previous message) the is-enabled check occurs somewhere else, far from where the diagnostic is logged.

The methods `log(LintWarning)` and `log(Warning)` would behave the same. The reason I want both methods to exist is simply because I want `LintWarning` to not be a subclass of `Warning`.

Here's why I think that's important:
* We are using the same English word "warning" to describe the following two things:
  * Generic compiler warnings that have nothing to do with lint. Example: `Warnings.InvalidUtf8InClassfile`
  * Compiler warnings that have an associated lint category. Example: `Warnings.MissingDeprecatedAnnotation`
* But really two things are distinct: they do not overlap, and every compiler "warning" is one or the other (and never both). _Practically speaking_, "generic warnings" and "lint warnings" are just as distinct from each other as are `Error`, `Note`, and `Fragment`. Therefore, we can make them peer classes with no inheritance relationship.
* Why is this helpful? Because the stronger type checking prevents possible mistakes like this:

// somewhere in the code
LintWarning lw = ...;

// somewhere else in the code
Warning w = lw;
log.warning(pos, w);

The result of the above mistake would be a lint warning emitted that:
* Does not have the "[foo]" prefix; and
* Possibly escapes being suppressed by `-Xlint:-foo` as it should.

Put another way, I don't see any reason to make `LintWarning` a subclass of `Warning` - so why do it??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1868062530