RFR: 8359493: Refactor how aggregated mandatory warnings are handled in the compiler

[Maurizio Cimadamore]

On Fri, 13 Jun 2025 21:25:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
> 
> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
> 
> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 736:

> 734:     private MandatoryWarningAggregator aggregatorFor(LintCategory lc) {
> 735:         return switch (lc) {
> 736:         case PREVIEW -> aggregators.computeIfAbsent(lc, c -> new MandatoryWarningAggregator(this, Source.instance(context), c));

Can we save `Source` as an instance variable? I'm mildly worried about using the `context` instance field (which is used for lazy init of lint) more generally. (In fact, I was even thinking if it would make sense to have a `Supplier<Lint>` field that we create at construction, so that we don't have to save the `context` field at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161196847