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

[Maurizio Cimadamore]

On Mon, 28 Jul 2025 21:58:09 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Not sure I'm understanding you... the remaining short-circuit checks are using "local" `Lint` instances, not the root `Lint` instance; for example `checkPotentiallyAmbiguousOverloads()`...

At the start of `checkPotentiallyAmbiguousOverloads()`, we check:


if (!lint.isEnabled(LintCategory.OVERLOADS))
            return;


Now, I do not see any other code setting this lint. There are a couple of visitors elsewhere that do, but these operations seems rather local. To my eyes, this is check applied to the root lint. Then there's a more subtle check (that I missed) below:


// Allow site's own declared methods (only) to apply @SuppressWarnings("overloads")
        methodGroups.forEach(list -> list.removeIf(
            m -> m.owner == site.tsym && !lint.augment(m).isEnabled(LintCategory.OVERLOADS)));


This "augments" the lint with one of the symbols to check, and removes the symbol if it is annotated with `@SuppressWarnings("overloads")`.

This code seems convoluted, in the sense that you don't really need to augment anything here? The toplevel check looks for enablement, whereas this loop looks for suppression. To implement the latter all you need is to check is a certain category appears suppressed in the given symbol. Note though: if we have a `@SuppressWarnings` on the enclosing class I don't think that will be considered. I will need to test a bit more.

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

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