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

[Jan Lahoda]

On Tue, 8 Apr 2025 19:51:36 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:
> 
>   Refactoring/cleanup for handling of ending positions.

In the sketch I was doing a few days back, I was peeking at forcing some kind of `EndPosTable` argument to `TreeInfo.endPos`, but I shied away as it seemed to complicate things. Here I see it is not as bad as I thought, but still it spreads a bit.

I see the value in avoiding special field and code path for the AST nodes for which the end pos is mandatory, in addition to the optional EndPosTable.

I think I would still slightly prefer the specialized fields, esp. if the impact on mostly unrelated outside code (like TransPatterns and Gen) could be eliminated. I would like to investigate if we can drop the EndPosTable altogether, although that is unlikely to happen before JDK 25 RPD1 (maybe 2). But, there is, of course, a possibility that the removal of EndPosTable won't happen, at which point we would have the duplication.

But, I can live with a patch long the lines here adding EndPosTable to `TreeInfo.endPos` if needed. Should we drop the EndPosTable as some point, we can drop the new EndPosTable argument. If not, we would preserve it. It is not what I would do, but I don't think either of the solutions is clearly wrong.

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

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2794448022