RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution
Archie Cobbs
acobbs at openjdk.org
Thu Jul 3 19:02:27 UTC 2025
This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
In addition, several other factors complicate things:
* Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
* Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
* Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
* Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
* Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
* Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
* Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
-------------
Commit messages:
- Merge branch 'master' into JDK-8348611 to fix conflicts.
- Merge branch 'MandatoryWarningCleanup' into JDK-8348611
- Address review suggestions.
- Remove assumptions about mandatoryness from the MandatoryWarningAggregator.
- Merge branch 'MandatoryWarningCleanup' into JDK-8348611
- Merge branch 'master' into MandatoryWarningCleanup
- Merge branch 'MandatoryWarningCleanup' into JDK-8348611
- Move (most) SOURCE_LEVEL flags into compiler.properties.
- Add DiagnosticFlag support to compiler.properties and put AGGREGATE there.
- Apply some review suggestions.
- ... and 76 more: https://git.openjdk.org/jdk/compare/25ed36f3...ec02990a
Changes: https://git.openjdk.org/jdk/pull/24584/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24584&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8348611
Stats: 1999 lines in 57 files changed: 1065 ins; 587 del; 347 mod
Patch: https://git.openjdk.org/jdk/pull/24584.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584
PR: https://git.openjdk.org/jdk/pull/24584
More information about the compiler-dev
mailing list