JDK 10/11 RFR of JDK-8189146: Have use of "var" in 9 and earlier source versions issue a warning

[joe darcy]

Hi Maurizio,


On 1/12/2018 5:13 AM, Maurizio Cimadamore wrote:
> Hey Joe,
> here's my take on the patch:
>
> http://cr.openjdk.java.net/~mcimadamore/8189146/
>
> it is similar to what I initially proposed, but I had to fight a bit 
> with the parser in order to get rid of the duplicate warnings. The 
> issue is that warnings can be reported both through the 'parseType' 
> path and the 'variableDeclaratorRest' path, as the overlapping between 
> the two is non trivial (sometimes javac parses a local var decl type 
> as a type, sometimes as an expr, depending on whether javac is 'sure' 
> that the thing is a variable decl - whose production is ambiguous with 
> almost anything else :-)).

Yes, the simple correspondence between the grammar productions and the 
code gets fuzzy without an unambiguous lookahead token to force a unique 
code path ;-)

>
> The solution is to add a flag to the isRestrictedLocalVarName so that 
> in certain cases the warning generation is suppressed. I have also 
> consolidated the treatment of the errors occurring because of the use 
> of 'var' in a compound declaration - now the errors are reported in 
> the same place where errors about 'var and array' is reported, which 
> makes a bunch of things easier.
>
> Lastly, I've cleaned up some of the diagnostic used - as they were 
> using a diagnostic argument which was alway set to the name 'var'. I 
> believe that's a leftover of when we accepted both 'var' and 'val', 
> and I have now removed it.

I was curious about that; an artifact of supporting "val" and "var" 
makes sense.

>
> I believe what comes out of the compiler is in sync with what you 
> wanted, but the patch is not as trivial as we originally had hoped, 
> which, in my mind, makes it more for 11 than for 10.

Hmm. I agree the current patch is more intricate than desired for this 
stage of JDK 10.

Arguably the largest compatibility impact from var is no longer being 
able to use var as a type name, at least it is the  impact that might be 
hardest to overcome in terms of having to rename a type rather than 
rename a variable. So for a patch appropriate for 10 at this stage, I'll 
prepare a simple patch for consideration that just warns on type name. 
Then if that is acceptable for 10, your patch could go into JDK 11 under 
a follow-up bug.

Thanks,

-Joe