RFR: 8334248: Invalid error for early construction local class constructor method reference [v3]

[Maurizio Cimadamore]

On Sat, 15 Jun 2024 15:28:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The new "flexible constructors" JEP 482 specifies that a local class declared in an early construction context does not have an immediate outer instance, i.e., it has the same behavior as an anonymous class would in that situation.
>> 
>> However, the compiler still (incorrectly) tries to verify that an outer instance exists in the case of a method reference to the local class' constructor.
>> 
>> Example:
>> 
>> 
>> 
>> import java.util.function.Supplier;
>> 
>> class EarlyLocalCtorRef {
>> 
>>     EarlyLocalCtorRef() {
>>         class InnerLocal { }
>>         this(InnerLocal::new);
>>     }
>> 
>>     EarlyLocalCtorRef(Supplier<Object> s) {
>>     }
>> }
>> 
>> 
>> Expected output: Successful compilation.
>> 
>> Actual output:
>> 
>> 
>> EarlyLocalCtorRef.java:5: error: cannot reference this before supertype constructor has been called
>>         this(InnerLocal::new);
>>              ^ 
>> 
>> 
>> The fix is to not look for an implicit outer instance for classes that don't have one when encountering a constructor method reference.
>> 
>> **NOTE:** The test added here will fail until [JDK-8333313](https://bugs.openjdk.org/browse/JDK-8333313) is fixed.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Refactor resolveImplicitThis() to respect actual outer instance.
>  - Add Maurizio's innermostAccessibleEnclosingClass() and hasOuterInstance().
>  - Merge branch 'master' into JDK-8334248
>  - Future-proof bug fix vs. new & improved semantics of hasOuterInstance().
>  - Don't require outer instance for early construction local class method ref.

Thinking more, my understanding of the spec is that we should never check for `hasOuterInstance` in `Attr`/`Resolve`. The spec seems to be defined in terms of the innermost enclosing instance (e.g. `getEnclosingType`), and then adds extra checks, to make sure the enclosing type is indeed accessible.

So, when we see either `new A`, or `A::new`, we should check:

* if A has as an enclosing instance. If not, there's nothing more to check.
* if the innermost enclosing instance of A is O, then we need to check if the expression occurs in the early-construction context for O. If so, error.

I don't think stuff like `NOOUTERTHIS` should even play a role here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19705#issuecomment-2173117187