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

[mcimadamore]

This PR contains the implementation for the third iteration of the Flexible Constructor Bodies 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.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change requires a CSR request matching fixVersion 24 to be approved (needs to be created)

Issues

• JDK-8338288: Compiler Implementation for Flexible Constructor Bodies (Third Preview) (Sub-task - P4)
• JDK-8322882: Null pointer error when compiling Static initializer in a local class (Bug - P4) ⚠️ Issue is not open.
• JDK-8334248: Invalid error for early construction local class constructor method reference (Bug - P4)
• JDK-8330037: Compiler produces invalid bytecode for method class creation from static method (Bug - P4)

Reviewers

• Jan Lahoda (@lahodaj - Reviewer)
• Vicente Romero (@vicente-romero-oracle - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/21410/head:pull/21410
$ git checkout pull/21410

Update a local copy of the PR:
$ git checkout pull/21410
$ git pull https://git.openjdk.org/jdk.git pull/21410/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 21410

View PR using the GUI difftool:
$ git pr show -t 21410

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/21410.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back mcimadamore! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@mcimadamore The following label will be automatically applied to this pull request:

• compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mcimadamore]

/csr

[openjdk]

@mcimadamore has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@mcimadamore please create a CSR request for issue JDK-8338288 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

[mcimadamore]

/solves 8322882
/solves 8334248

[openjdk]

@mcimadamore
Adding additional issue to solves list: 8322882: Null pointer error when compiling Static initializer in a local class.

[openjdk]

@mcimadamore
Adding additional issue to solves list: 8334248: Invalid error for early construction local class constructor method reference.

[mcimadamore]

/issue remove JDK-8341469

[openjdk]

@mcimadamore The issue 8341469 was not found in the list of additional solved issues. The list currently contains these issues: 8334248, 8322882

[mlbridge]

Webrevs

• 00: Full (118e1252)

[archiecobbs]

FYI, I verified that this patch also fixes JDK-8330037, which is a variant of the "you can't capture a free variable across a static method boundary" problem.

[mcimadamore]

/solves 8330037

[openjdk]

@mcimadamore
Adding additional issue to solves list: 8330037: Compiler produces invalid bytecode for method class creation from static method.

[lahodaj]

Looks good to me.

[vicente-romero-oracle]

lgtm