RFR: 8177466: Add compiler support for local variable type-inference

[Maurizio Cimadamore]

On 21/09/17 01:06, Vicente Romero wrote:
>>> Regarding attribLazyConstantValue, I think it's probably better to 
>>> use baseType() there too. But I will have to double check if lack of 
>>> baseType is creating issues.
>> ok thanks for the clarification, yes I think that we need to 
>> investigate if you need to use baseType() for lazy evaluation too 
>> which should be triggered by:
>>
>> final var s = "Hello!" right?
> Yes, lazy evaluation would happen for final vars. 
I have investigated this a bit more. The short story is that the 
submitted patch is a bit inconsistent with the rest of javac, but this 
inconsistency is harmless.

Long story below :-)

When you have a final variable whose initializer is a compile-time 
constant, the variable symbol will always get a 'constant value'. This 
constant value will be accessed from Attr::checkIdInternal (see call to 
VarSymbol.getConstantValue), so that, if a const value is found on the 
variable, the resulting type from type-checking the var identifier, will 
be set to be a constant value.

So, in the case of final variable, it doesn't really matter much whether 
the variable type is itself a constant type or not - as checkIdInternal 
will always look at the symbol's constant value and override the 
resulting type that way. That is why, despite the missing 'baseType()' 
call, everything worked as expected.

Now, the opposite is not true - if you have a non-final variable with a 
compile-time constant initializer:

String s = "";

In this case the symbol for 's' won't receive any constant value. So 
Attr::checkIdInternal will return whatever type is associated with the 
variable. So, in this case it matters a lot as to whether the variable 
type is constant or not - if, by accident, the type of 's' was set to a 
constant type, the compiler will start treating 's' as a compile-time 
constant, which would be wrong.

So, as a general rule, the type of variables is always a non-constant 
type in javac. But, some variable symbols (those for final variables 
with constant initializers) might have a constant value attached to 
them, which Attr then uses in order to propagate constant-ness around.

I've fixed this, and also rewrote and added comments to the projections 
in types. I will run some tests and I'll submit another patch for review 
tomorrow.

Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170921/40db86d2/attachment.html>