RFR: 8359493: Refactor how aggregated mandatory warnings are handled in the compiler
Maurizio Cimadamore
mcimadamore at openjdk.org
Mon Jun 23 10:08:33 UTC 2025
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.
Great work as usual. Moving the aggregation logic to `Log` seems generally a big win, both for clients and for us, as it seems generally easier, in the new code, to guarantee that all mandatory warnings get the same treatment.
src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 731:
> 729: .flatMap(List::stream)
> 730: .forEach(this::report);
> 731: aggregators.clear();
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?
-------------
PR Review: https://git.openjdk.org/jdk/pull/25810#pullrequestreview-2949469743
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161219923
More information about the compiler-dev
mailing list