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