RFR: 8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features [v14]

[Archie Cobbs]

On Fri, 28 Feb 2025 17:56:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Thanks for giving a try. I have an initial question about the code. It seems like it stores all the "reports" and all the "declarations" in flat lists. Then we flush the reports once per compilation unit.
> 
> This means we still have to do a lot of work to associate reports with declarations.

I originally was handling things "as they come", based on the assumption that reports always occur prior to the completion of their containing declaration, but that's not true (`dangling-doc-comment` violates it).

So I switched to storing everything then doing the match up at the end, but the flushing process still needs to be optimized to make it linear time.

> What I had in mind was to basically do the association when `endDecl` is called. E.g. once you see a field declaration, at that point you can defer all the lint warnings that have been created for that field. This probably needs some `startDecl` (maybe). I'm sure you considered this alternative -- I'm curious as to why it was rejected?

See previous comment - reports can come in "late", after their containing declaration. I did have a `startDecl` before but it was no longer needed once I added the logic to accommodate late reports.

> Separately, I feel we're calling endDecl way more than what I had in mind. E.g. in my mental model the start/end of a "decl" is only relevant if it can have some suppression attached to it. I see the code calls out endDecl for things like binding variables in patterns and method parameters -- so I'm not sure I follow...

First, we are only calling `endDecl` on declarations of: methods, packages, classes, variables, methods. I just added an assertion check similar to the one you linked to in 45c2aacff7a and it isn't firing so that's good.

As for _which_ variable declarations, we need to handle any that support `@SuppressWarnings` annotations, plain and simple - even if they can't have initializers. including variables in patterns and method parameters. The reason is because we may want to handle any future _lexical_ issues contained therein.

For example, after implementing [JDK-8271171](https://bugs.openjdk.org/browse/JDK-8271171), we would still want the following suppression to work:

public record Example(int x) {

    public void method(Object f) {
        switch (f) {
        case Example(@SuppressWarnings("funky-unicode-escapes") int funkyVariable\u004Eame):
            break;
        default:
            break;
        }
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2691431424