[lworld] RFR: 8263900: [lworld] Make .default a separate node type in the parser.

[Jesper Steen Møller]

On Wed, 24 Mar 2021 10:28:28 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> I have made one high level pass over the changes, more verifying on the boiler plate parts. Need to delve deeper in Attr, Gen, Parser, TransValues, will do this tomorrow.
>> 
>> Here are some comments so far:
>> 
>> (1) Is DefaultExpression better named as DefaultInstance or DefaultValue ??
>> (2) Should com.sun.tools.javac.tree.JCTree.JCDefaultExpression#getClazz - for consistency sake return JCExpression ??
>> (compare similar cases in JCTree)
>> (3) Do we need a visitor in SourceComputer in CRTable.java ??
>
> Here are cumulative comments:
> 
> (1) Is DefaultExpression better named as DefaultInstance or even better DefaultValue ??
> (2) Should com.sun.tools.javac.tree.JCTree.JCDefaultExpression#getClazz - for consistency sake return JCExpression ??
> (compare similar cases in JCTree)
> (3) Should JCDefaultExpression#getClazz be named getType() a la JCTypeCast, JCNewArray, JCVariableDecl, JCInstanceof ...
> (4) Do we need a visitor in SourceComputer in CRTable.java ??
> (5) Attr.java:4464: reference to .default needs to be removed from comment
> (6) Attr.visitDefaultExpression: sitesym seems to be unused variable declaration.
> (7) This program: 
> primitive class X {
>     Object o2 = java.util.default;
> }
> 
> generates this strange error: 
> error: package java does not exist
>     Object o2 = java.util.default;
>                                ^
> 1 error
> (That it emits the same message without the patch notwithstanding)
> 
> I think we should attribute the clazz as a TYP_PCK and for package case emit an error.
> (8) com.sun.source.util.TreeScanner#visitDefaultExpression: Eliminate the local and directly return ?
>  
> Let me know if you have any questions/clarifications.
> 
> Thanks for your effort, this looks very promising prework for the poly expr typing task

Regarding (7), I hit that earlier as well - but it is a entirely seperate bug, also available in the released product:

% javac -version
javac 16
% cat X.java 
public class X {
    void x() {
        Class c = java.lang.class;
    }
}
% javac X.java    
X.java:3: error: package java does not exist
        Class c = java.lang.class;
                      ^
1 error

I get the same confusing error with e.g. "new java.lang()"

This bug goes back to at least Java 11, but Java 8 u232 appears to get it right, explaining that there's no java.lang class. I'm guessing it may have come in with Jigsaw.

While I might be able to fix this locally, I think it should really be addressed in the main repo first. I tried finding the bug for it, but didn't find it -- would you like me to report it?

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

PR: https://git.openjdk.java.net/valhalla/pull/370