RFR: 8358604: Trees for `var` do not have end positions

Liam Miller-Cushon cushon at openjdk.org
Tue Jun 10 15:20:29 UTC 2025


On Tue, 10 Jun 2025 14:32:06 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > I guess I would like to understand the rationale for adding the end position for the type....there's a question why this specific synthetic tree should have an end position, while the other shouldn't.
> 
> @cushon is better positioned (no pun intended) to answer that question than me. In the issue, this rationale is given:

The position information is useful for Tree API clients that want to do refactorings (e.g. to replace the type of a particular variable, even if it's `var`), or emit diagnostics. I've seen the specific example of `var` come up a number of times, it seems to be more common that other synthetic trees, perhaps because historically none of the nodes contained in a `VariableTree` were ever synthetic and now the type is but only for some trees.

As a general approach I think it's helpful if javac provides a post-flow AST to clients with minimal rewriting/lowering, so it's possible to map back to the original source code, while still exposing information from flow to clients (e.g. the inferred types of local variables).

I think this is closely related to discussion in https://bugs.openjdk.org/browse/JDK-8024098, and looking at that bug again I see there's an issue specifically about `var` that I'd forgotten about: https://bugs.openjdk.org/browse/JDK-8268850

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

PR Comment: https://git.openjdk.org/jdk/pull/25664#issuecomment-2959670396


More information about the compiler-dev mailing list