RFR JDK-8188225: AST could be improved in presence of var types.
Jan Lahoda
jan.lahoda at oracle.com
Mon Oct 2 15:35:33 UTC 2017
Hello,
JShell produces not ideal errors related to local variable type
inference in some cases:
---
jshell> var i = () -> {};
| Error:
| incompatible types: java.lang.Object is not a functional interface
| var i = () -> {};
| ^------^
---
Better would be:
---
jshell> var i = () -> {};
| Error:
| cannot infer type for local variable i
| (lambda expression needs an explicit target-type)
| var i = () -> {};
| ^---------------^
---
(which is the error produced by javac)
The AST model could also be improved for local variables whose type have
been inferred (which also improves the jshell errors in some cases):
- for "var i = 0;", the VariableTree.getType() will be null even after
attribution, but for: "for (var i : Arrays.asList(0, 1)) {}", the
VariableTree.getType() will be filled in by Attr. (The inferred type is
also filled in for lambda parameters.) This is not only inconsistent,
but also Attr.PostAttrAnalyzer.visitVarDef may fill in the type with an
ErroneousTree (with a wrong position). The proposal here is to always
fill in the type for consistency, and to consistently use NOPOS for the
synthetic type position
-for "var i = 0;" SourcePositions.getStartPosition does not return a
proper starting position (the position of "var"), but rather the
position of the synthetic type, if any (which can also be ErroneousTree)
or the position of the variable name. The proposal here is to remember
the real start of the variable and return it.
Bug: https://bugs.openjdk.java.net/browse/JDK-8188225
Webrev: http://cr.openjdk.java.net/~jlahoda/8188225/webrev.00/index.html
What do you think?
Thanks,
Jan
More information about the compiler-dev
mailing list