On Mon, 26 Jan 2026 16:42:39 GMT, Liam Miller-Cushon <[email protected]> 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 incrementally with one 
> additional commit since the last revision:
> 
>   Rename mapPos to endpos, there is no longer an end position map

Looks good to me, thanks!

(Please give Maurizio and others some time to add more comments if needed.)

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28610#pullrequestreview-3711398649

Reply via email to