Analyzer fails initializing_formal_final_test

[MichaelRFairhurst]

I'm having difficulty pinning down whether this is still latest spec behavior, and what the rationale for it was. Given that neither the analyzer nor CFE pass this test, it seems like maybe it should be removed?

edit: the analyzer is incorrect here, and this test is valid. Keeping issue open for us to make a fix.

class A {                                                                        
  var x, y;                                                                      
  // This should cause an error because `x` is final when accessed as an         
  // initializing formal.                                                        
  A(this.x)                                                                      
      : y = (() {                                                                
          /*@compile-error=unspecified*/ x = 3;                                  
        });                                                                      
}

From the spec:

Initializing formals constitute an exception to the rule that every formal parameter introduces a local variable into the formal parameter scope (\ref{formalParameters}).
When the formal parameter list of a non-redirecting generative constructor contains any initializing formals, a new scope is introduced, the {\em formal parameter initializer scope}, which is the current scope of the initializer list of the constructor, and which is enclosed in the scope where the constructor is declared.
Each initializing formal in the formal parameter list introduces a final local variable into the formal parameter initializer scope, but not into the formal parameter scope; every other formal parameter introduces a local variable into both the formal parameter scope and the formal parameter initializer scope.

There are no other references to "formal parameter initializer scope," and the section on initializer lists doesn't reference scopes at all, but rather magically talks about:

For each such declaration $d$, if $d$ has the form \code{$finalConstVarOrType$ $v$ = $e$; }
then $e$ is evaluated to an object $o$
and the instance variable $v$ of $i$ is bound to $o$.

where some scope of evaluation is assumed but not expressed. Similarly, the "formalParameters" section doesn't mention anything either.

I get the feeling, best I can make of this, that the test is correct. However, I'm not confident there, and I'm suspicious of the value that this complexity in the spec adds.

[leafpetersen]

I think this test is consistent with the resolution of #26655 .

My testing shows the CFE passing this test, but the analyzer failing it. Both implementations pass a simpler version where the initializer list is y = (x = 3).

cc @eernstg @lrhn to check me on my interpretation of #26655

[eernstg]

The spec excerpt

Initializing formals constitute ... is declared.

specifies the current scope for the initializer list of a constructor with initializing formal parameters. Any expressions in the initializer list are resolved according to the current scope, and there is no need to mention at each point where an expression is considered which scope is current. That approach is used everywhere; e.g., when considering the meaning of an expression in the body of a function we're implicitly using the fact that its current scope (unless nested in something like function literal etc.) is the body scope of the function.

So x is treated like a final local variable here: It is in scope, but it only admits read access. Hence it is an error to have x = 3 in the body of the function literal in the example, as expected by the test.

.. if $d$ has the form \code{$finalConstVarOrType$ $v$ = $e$; }

This one is about initialization of instance variables whose declaration includes an initializing expression, so that's completely separate from the semantics of initializer lists. In that case the current scope is the instance scope of the class, and there is a special rule which makes it a compile-time error to reference this in such an initializing expression:

It is a compile-time error if \THIS{} appears, implicitly or explicitly, in ...
the initializer of an instance variable.

So you could say that the current scope for $e$ is "the instance scope minus this".

You could claim that we should be more forgiving in the body of a function literal which is statically guaranteed to not run before initialization list evaluation has completed (which makes it similar to expressions in the constructor body, or indeed the body of any instance member), which would mean that it wouldn't hurt to allow such a function literal body to access this, even though it occurs in an initializer list. But I don't think it's worth the trouble, developers could just move it out and make it a private instance member, and then they can freely use this in the body: y = _auxMethod.

It's possible that we can make the specification of scoping simpler and more readable, but I think the current approach is at least reasonable: Scopes are specified for each syntactic location where a term occurs for which one or more names may be looked up (e.g., all locations where an expression can occur), and the semantics of all such terms will never talk about scoping unless they introduce a new scope, they always just rely on looking up names in the 'current' scope.

For lookups, it's enough to know that we have a scope which is current for a certain location, it introduces a certain set of bindings (statically, and the dynamic semantics just needs to make it work as if we had all those scopes and looked up names lexically), and it has another specific scope as its enclosing scope. We mention each situation where a new scope is introduced, otherwise we just use the rule that when t' is a subterm of t and t doesn't introduce a new scope, t' has the same current scope as t.

@MichaelRFairhurst, does that make it more meaningful?

[MichaelRFairhurst]

@eernstg Thanks, that does help!

@leafpetersen you're right, the CFE does pass this. Not sure what test I had run that gave me the impression otherwise.

Changing this to an analyzer issue.