On Mon, 26 Jan 2026 11:17:53 GMT, Maurizio Cimadamore <[email protected]> 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
