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

[Jan Lahoda]

On Thu, 22 Jan 2026 11:55:15 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compiler-dev@ thread](https://mail.openjdk.org/pipermail/compiler-dev/2025-November/032254.html).
>> 
>> I performed the refactoring in stages, preserving existing semantics at each step.
>> 
>> There are two known places where this changes existing behaviour that are reflected in changes to tests:
>> 
>> * `test/langtools/tools/javac/api/TestJavacTask_Lock.java` - this test asserts that calling `JavacTask#parse` first and then calling `#call` or `#parse` second will fail. The assertion that the test is currently expecting is thrown when the `EndPosTable` gets set a second time, and this change means that no longer results in an exception. If desired `JavacTask#parse` could be updated to explicitly check if it is called twice and fail, instead of indirectly relying on the `EndPosTable` for that.
>> 
>> * `test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java` - there's a comment that 'ideally would be "0", but the positions are not fully set yet', and with the new approach the end position is available to the test, so it resolves the comment. Also the test logic didn't handle platform specific line ending variations correctly, so I updated it to work on windows now that end positions are present.
>
> 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

I think this is very good, thanks. I've left two comments inline - one about the `parse` then `call`, and one nit in the other test. I also would like to run some more tests/experiments.

test/langtools/tools/javac/api/TestJavacTask_Lock.java line 72:

> 70:         fm = comp.getStandardFileManager(null, null, null);
> 71:         try {
> 72:             MethodKind first = MethodKind.CALL;

I think it would be good to preserve the behavior (i.e. prevent `parse` followed by `call` or `parse`). Otherwise, I am not sure if there may not be some a bit surprising effects (like calling `parse`, then `analyze` then `parse` again and `analyze` again might lead to some weird errors). If there would be a reason to relax this restriction, it would probably merit its own PR and own investigation of effects.

test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java line 127:

> 125:                     int line = (int) d.getLineNumber();
> 126:                     int col = (int) d.getColumnNumber();
> 127:                     String substring = implCode.split("\\R")[line - 1].substring(col - 1, col);

Nit - there could be a check that `d.getEndPosition() - d.getStartPosition()` is equal to `1`, that would make the test a bit stricter.

But this is a great change, I think!

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

PR Review: https://git.openjdk.org/jdk/pull/28610#pullrequestreview-3705362948
PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2727037870
PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2727004535