RFR: 8338288: Compiler Implementation for Flexible Constructor Bodies (Third Preview)

[Jan Lahoda]

On Tue, 8 Oct 2024 14:42:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the implementation for the third iteration of the [Flexible Constructor Bodies](https://openjdk.org/jeps/492) feature.
> 
> While the feature remains largely unchanged from the previous iteration, this PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via new, or, indirectly, via super. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what should happen, in the various cases.
> 
> #### Member inner classes
> 
> Whenever we see `new M()` where `M` is a member inner class, we need to lookup some `E.this` (where `E` is a class enclosing `M`), given none is provided. This same issue is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking `new M()`.
> 
> The lookup process for should look at all the enclosing instances available to us, and pick the innermost enclosing instance of type `E` such that `E` is a subclass of `M`'s enclosing class. It should be the case that  `E.this` is accessible (e.g. not in E‘s early construction context) or a compile-time error should occur.
> 
> This new check is defined in `Resolve::findSelfContaining`.
> 
> #### Local and anonymous inner classes
> 
> When creating local and anonymous inner classes defined in a `static` method, we should *not* check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this (such classes have no enclosing instance). What matters, for local and anon classes defined in `static` methods, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.
> 
> This new check is defined in `Resolve::findLocalClassOwner`. While writing the code and looking at tests, I realized that existing diagnostics were not sufficient to capture this new condition. So I added a new one.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21410#pullrequestreview-2381748224