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

[Archie Cobbs]

On Tue, 25 Feb 2025 12:36:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Question -- in a [related change](https://github.com/openjdk/jdk/pull/23281) we cleaned up the deferred lint handler code to use trees instead of positions, as positions were too weak. This PR now adds a parsing mode which effectively uses position again.

Well to be precise, the earlier change didn't really alter how we tracked anything, it just tightened up the declared types in the Java source (from `DiagnosticPosition` to `JCTree`) - the same actual objects are being used for tracking as before. So the code was "pretending" to use positions before, but it really was using trees.

> The fact that we have two ways of doing things worries me a bit -- if we want to keep using deferred lint handler in all places (both parser and after parsing) either it works on the lowest common denominator (the position), or we make some extra work in contexts where we only have a position but we need a tree.

I agree with the gist of what you're saying, i.e., Why have two ways of doing something?

So if I understand correctly, you and @lahodaj are suggesting the following:

1. Don't change how `DeferredLintHandler` tracks pending warnings, i.e., by their innermost containing `JCTree` declaration node.
1. Add another layer of "deferral", this one private to the parser, in which lexical warnings are deferred until their innermost `JCTree` declaration is created, at which time they can then be passed on to `DeferredLintHandler` like normal.

In my opinion Step 2 must be done in such a way that any future lexical warnings are able to "easily" use it, as we have several lexical lint warning feature requests queued up such as [JDK-8271171](https://bugs.openjdk.org/browse/JDK-8271171), [JDK-8210681](https://bugs.openjdk.org/browse/JDK-8210681), [JDK-6764629](https://bugs.openjdk.org/browse/JDK-6764629).

I will take a look at doing something like this in the parser. Basically, following Maurizio's steps.

We still have two ways of doing things but at least this way they'll be a little more compartmentalized... :)

Thanks for the comments.

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

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