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

[Vicente Romero]

Hi Maurizio,

On 09/21/2017 08:45 AM, Maurizio Cimadamore wrote:
>
>
>
> 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.

thanks for the investigation, yes it all makes sense now

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