RFR: 8359493: Refactor how aggregated mandatory warnings are handled in the compiler
Archie Cobbs
acobbs at openjdk.org
Mon Jun 23 15:23:34 UTC 2025
On Mon, 23 Jun 2025 09:36:22 GMT, Maurizio Cimadamore <mcimadamore 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/comp/Check.java line 248:
>
>> 246: }
>> 247: }
>> 248: Optional.ofNullable(warningKey)
>
> I think I'd prefer a regular `if (warningKey != null) { log.mandatoryWarning(...) }`, as it seems generally "flatter".
It's a style thing and I'm happy either way. I'll fix.
> Is there a "cleanup race" here? E.g. this method clears the aggregator enum map. But then Log.clear walks that map and calls `clear` on each aggregator -- but if the map is empty, nothing will get cleared?
Yep - there is a bit of inconsistency here: `reportOutstandingNotes()` is treating aggregators as things that are created, used, and then discarded, whereas `log.clear()` is treating them as being created once and then used, cleared and re-used multiple times. Logically it's the same result but it looks weird. I'll fix to just clear the map in both cases.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161887478
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161885108
More information about the compiler-dev
mailing list