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

[Maurizio Cimadamore]

On Fri, 30 May 2025 01:51:40 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Revert TreeInfo.endPos() refactoring except for "bracePos" renaming.
>  - Merge branch 'master' into JDK-8350212
>  - Merge branch 'master' into JDK-8350212 to fix conflict.
>  - Update copyrights.
>  - Refactoring/cleanup for handling of ending positions.
>  - Add missing variable decl end position.
>  - Add end position for variables coming from variableDeclaratorId().
>  - Track source end positions of declarations that support @SuppressWarnings.

Overall the changes look great, and much more minimal, thanks. I left few questions around for you to consider.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2063:

> 2061:             make_at(tree.pos());
> 2062:             T result = super.translate(tree);
> 2063:             if (endPosTable != null && result != null && result != tree) {

I wonder how this extra check for `result != null` was added. I mean, of course calling `replaceTree` with a null parameter seems suspicious -- should we add more formal null checks in the various end pos table methods? (it's ok if we do that in a separate PR)

test/langtools/tools/javac/parser/extend/TrialParser.java line 142:

> 140:         }
> 141:         toplevel.lineMap = S.getLineMap();
> 142:         this.endPosTable.setParser(null); // remove reference to parser

Not sure about these changes -- e.g. what was the test trying to do in the first place?

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

PR Review: https://git.openjdk.org/jdk/pull/23669#pullrequestreview-2880922602
PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2115631276
PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2115635388