RFR: 8350212: Track source end positions of declarations that support @SuppressWarnings [v3]

[Maurizio Cimadamore]

On Fri, 4 Apr 2025 21:42:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
>> 
>> Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available.
>> 
>> The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons.
>> 
>> Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing variable decl end position.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 704:

> 702:     protected void storeEnd(JCTree tree, int endpos) {
> 703:         endPosTable.storeEnd(tree, endpos);
> 704: 

If this method was non-void, we could make clients more fluent?

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 645:

> 643:         public PackageSymbol packge;
> 644:         /** Position of closing semicolon, optional. */
> 645:         public int endPos = Position.NOPOS;

Your code seems consistent with what we already do with `JCBody`, `JCSwicthExpression` and `JCSwitch`. There's nothing wrong with this approach, although if end positions are enabled, this might be a little wasteful, as we'll store end positions both in the table and in the tree... a possible alternative would have been to construct a "minimal" end pos table which only contains positions for some "important" declarations (even when end positions are switched off) since these seems necessary for the compiler to work correctly. That would allow all code to flow through the end pos table and maybe simplify the implementation of the `TreeInfo` method (as well as `storeEnd` in the parser). But I'll leave that option for you to consider.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2030816614
PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2030813961