RFR: 8268850: AST model for 'var' variables should more closely adhere to the source code

[Liam Miller-Cushon]

On Thu, 22 Jan 2026 17:16:06 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, if a local variable is declared using `var`, or if a lambda parameter has an inferred (missing) type, the AST model is a bit weird. The variable starts with `null` type, and the type is then replaced with a synthetic AST representing the real type. This (draft) PR is attempting to clean this up a little:
> - variables declared with `var` have `VarTypeTree` as the type. This is a new AST node that represents `var`. Positions are expected to be exact w.r.t. what is in the source code.
> - lambda parameters with inferred type would have `null` as the type. This is consistent with majority of the places in the AST where something is not part of the source code
> - for explicit parameters, the type is the real type, as before
> 
> This is not a compatible change, but I tried to partially write two clients, and it feels it wasn't too bad, and (hopefully) the new state is cleaner/more consistent.
> 
> There are some consistency comments:
> 
> - when the inferred types are inaccessible, javac (currently) sometimes produces a compile-time error, and sometimes does not; after reading the JLS, the error is indeed mandated in some cases, and not in others. `test/langtools/tools/javac/lvti/VarAccessibility.java` shows the cases
> - when the inferred types have potential for various types of warnings, javac (currently) sometimes produces those warnings, and sometimes not. The decision here is mostly implementation driven. I looked at the possibility to always produce the warnings, but there's https://bugs.openjdk.org/browse/JDK-8013222, from which it seems the original intent was to not produce the warnings. So, this PR currently will not produce warnings on the inferred types.
> 
> I was considering adding something similar to get JCVarDecl.DeclKind, but (based on the experience from the clients), it didn't feel strongly needed, as the type is determinable from `getType()`.
> 
> Any insights?
> 
> CC @cushon
> 
> Please also review:
> - CSR: https://bugs.openjdk.org/browse/JDK-8376736

Thanks for cleaning this up! Overall this approach looks good to me.

I tried updating some clients of these APIs, and the new `VAR_TYPE` tree worked as expected, and replaced some logic that was checking for `var` using start and end position information.

> lambda parameters with inferred type would have null as the type. This is consistent with majority of the places in the AST where something is not part of the source code

Most of the effects I saw from this change were related to this part, there were uses of the API relying on the inferred type for implicitly typed labels parameters being present. That is solvable by looking at the variable tree's type instead, but required a bit of additional plumbing. Overall though I think this makes sense and is consistent with having the AST model the source more closely.

One other effect of this change I noticed is that diagnostics on inferred lambda parameter types are no longer reported, e.g. the rawtypes diagnostic below, is that deliberate?

For example:


import java.util.function.Predicate;
import java.util.List;

abstract class Test {
  interface P<K, V> {
    void f(Predicate<V> p);
  }

  void test() {
    g().f(v -> !v.get(0).isEmpty());
  }

  @SuppressWarnings("rawtypes")
  abstract <K> P<K, List<List>> g();
}


This diagnostic is no longer reported after this change:


T.java:10: warning: [rawtypes] found raw type: List
    g().f(v -> !v.get(0).isEmpty());
          ^
  missing type arguments for generic class List<E>
  where E is a type-variable:
    E extends Object declared in interface List

Also I think this would resolve JDK-8358604 as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/29369#issuecomment-3789938666
PR Comment: https://git.openjdk.org/jdk/pull/29369#issuecomment-3789951108