RFR: 8268850: AST model for 'var' variables should more closely adhere to the source code [v2]
Jan Lahoda
jlahoda at openjdk.org
Wed Feb 25 11:11:53 UTC 2026
> 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
> - release note: https://bugs.openjdk.org/browse/JDK-8377951
Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
- Merge remote-tracking branch 'upstream-ssh/master' into JDK-8268850-vartype-ast
- Cleanup
- Adjusting tests.
- Merge branch 'JDK-8371683' into JDK-8268850-vartype-ast+JDK-8371683
- Updating header years.
- Fixing parsing with flags.
- Cleanup.
- Fixing parsing.
- Adding source-level restriction.
- 8371683: TYPE_USE annotation on var lambda parameter should be rejected
- ... and 19 more: https://git.openjdk.org/jdk/compare/6c39d1bb...d22966a5
-------------
Changes: https://git.openjdk.org/jdk/pull/29369/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29369&range=01
Stats: 911 lines in 33 files changed: 798 ins; 38 del; 75 mod
Patch: https://git.openjdk.org/jdk/pull/29369.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/29369/head:pull/29369
PR: https://git.openjdk.org/jdk/pull/29369
More information about the compiler-dev
mailing list