RFR: 8348611: Eliminate DeferredLintHandler and emit warnings after attribution [v10]

[Vicente Romero]

On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge branch 'master' into JDK-8348611 to fix conflict.
>  - Remove an unnecessary field.
>  - More simplification of LintMapper per review suggestions.
>  - More simplification of LintMapper per review suggestions.
>  - More refactoring to simplify LintMapper per review.
>  - Refactor LintMapper to clean up internal type hierarchy per review.
>  - Address a couple of review comments.
>  - Merge branch 'master' into JDK-8348611
>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef

src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 251:

> 249:         Lint lint,                                      // the Lint configuration that applies at this declaration
> 250:         Symbol symbol,                                  // declaration symbol (for debug purposes only; null for root)
> 251:         List<LintRange> children                        // the nested declarations one level below this node

not a proposal to do any change, but I think that if instead of having a tree-like structure in which each range has, potentially, a number of children, we had one list of ranges sorted by its starting point. I think that we could find the right range doing a binary search. We could actually have both: the current tree and a flat list of lint ranges for searches. Again probably not necessary for general cases but there could be corner cases as in machine generated code for which having a faster retrieval could make the difference. But again we can do that if needed in the future

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274581943