RFR: 8372948: Store end positions directly in JCTree [v6]

[Liam Miller-Cushon]

On Mon, 26 Jan 2026 11:17:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>>  - Fix DiagnosticGetEndPosition on windows
>>  - Debug DiagnosticGetEndPosition.java on windows
>>  - Update assertion for test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java
>>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>>  - 8372948: Store end positions directly in JCTree
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 675:
> 
>> 673:             case PREINC:
>> 674:             case PREDEC:
>> 675:                 return getEndPos(((JCOperatorExpression) tree).getOperand(RIGHT));
> 
> Is this big switch still needed? When would an end position not be set in this new world?

`JavacParser` is still only recording end positions for the trees where it calls `storeEnd`, so the same kinds of trees have end positions recorded in the new world. I think that potentially `JavacParser` could start recording end positions for all trees, and then this switch could be removed. I will investigate that more. If it works out, I wonder if it might be better as a separate follow-up change, to keep the initial refactoring to remove the end pos table as behaviour preserving as possible. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2727365379