RFR: 8177466: Add compiler support for local variable type-inference
vicente.romero at oracle.com
Thu Sep 21 12:52:27 UTC 2017
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev