<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 21/09/17 01:06, Vicente Romero
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:03c269e7-1f62-0747-0e24-0565c24a195a@oracle.com">
      <blockquote type="cite" style="color: #000000;">
        <blockquote type="cite" style="color: #000000;">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.
          <br>
        </blockquote>
        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:
        <br>
        <br>
        final var s = "Hello!" right?
        <br>
      </blockquote>
      Yes, lazy evaluation would happen for final vars.
    </blockquote>
    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.<br>
    <br>
    Long story below :-)<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Now, the opposite is not true - if you have a non-final variable
    with a compile-time constant initializer:<br>
    <br>
    String s = "";<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Maurizio<br>
  </body>
</html>