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

[Maurizio Cimadamore]

On Fri, 21 Feb 2025 21:29:09 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.
>> 
>> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's:
>> * #23167
>> * #23281
>> * #23400
>> * #23669
>> * #23730
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8350514' (split out as sub-task) into JDK-8224228.
>  - Refactor MandatoryWarningHandler to support dynamic verbosity.

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. 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.

Now, in Parser, I see that `reportDanglingComment` was using a tree (which should be better?) but is reverted to work on position by this PR. There's also a couple of lexer warnings issued by the tokenizer -- I wonder if it should be possible to find a tree in there (but I'll come back to that)

As for preview warnings, all the usages of such warnings in the parser are of the kind:


checkSourceLevel(pos, Feature.XYZ);
// keep parsing


The problem is, of course that, in parsing we're not in a top-down visitor, so we can't push/pop the deferred lint handler correctly (to make sure that all lint warnings are associated to the correct program element). That said, instead of reporting the warning directly, we could *buffer* them, and then report them against the deferred lint handler once we know to which declaration they belong to (which we can do once the parser creates such declaration node).

I guess what I'm envisioning is something like this:

* the compiler sees use of a preview feature deep inside the body of method `m`
* the compiler stash the lint warning for this preview feature as an action in a todo list
* eventually, the compiler will create the tree node for the enclosing method `m`
* at this point we have a suitable tree, so we can "push" `m` onto the deferred lint handler
* run all the pending lint actions in the queue
* pop `m` from the deferred lint handler

If we get this right, I think such a mechanism can also be reused by the tokenizer, and seems less invasive on deferred lint handler -- which will now be back to one "mode", and won't have to do expensive things such as trying to figure out which tree is associated to which lint warning pos.

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

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