8294942: Compiler implementation for Record Patterns (Second Preview) #10814

lahodaj · 2022-10-21T11:56:50Z

This is a partial implementation of JEP 432: Record Patterns (Second Preview) and JEP 433: Pattern Matching for switch (Fourth Preview). Namely, it implements:

removal of named record patterns
(preview) type inference for type test and record patterns
cleaner switch case specification (e.g. no combination of null constants and type test patterns)
fixing exhaustiveness of certain switches

The patch does not contain support for record patterns in enhanced for statements, that is part of a separate pull request.

For more information on the changes please see:

the JEPs: JEP 432 and JEP 433
the CSRs: JEP 432 - JDK-8294944 and JEP 433 - JDK-8294946
the current specification draft

Current total specdiff for both this PR and the enhanced for PR is here.

Any feedback is welcome.

Thanks!

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 to be approved

Issues

JDK-8294942: Compiler implementation for Record Patterns (Second Preview)
JDK-8294945: Compiler implementation for Pattern Matching for switch (Fourth Preview)
JDK-8294944: Compiler implementation for Record Patterns (Second Preview) (CSR)

Reviewers

Maurizio Cimadamore (@mcimadamore - Reviewer) ⚠️ Review applies to 77c34fcf
Vicente Romero (@vicente-romero-oracle - Reviewer) ⚠️ Review applies to 5afc6023

Contributors

Aggelos Biboudis <abimpoudis@openjdk.org>
Maurizio Cimadamore <mcimadamore@openjdk.org>

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 10814

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

Using diff file

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

bridgekeeper · 2022-10-21T11:56:55Z

👋 Welcome back jlahoda! 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 · 2022-10-21T12:00:13Z

@lahodaj 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.

biboudis

Some minor comments.

biboudis · 2022-10-25T09:52:39Z

test/langtools/tools/javac/patterns/NewCaseStructureTest.java

+                       return switch (o) {
+                           case Integer i when i > 0 -> 0;
+                           case 0 -> 0;
+                           case Integer i -> 0;


This case is not needed, right?

Well, omitting the unconditional case would make the switch non-exhaustive. While that would not be a blocker for a testcase that verifies that error are reported, I think it is cleaner to avoid unrelated errors in the source code.

I checked: the exhaustivity errors are not reported after these points. The dominance check short circuits the structure test. But I see what you mean: while the tests do not isolate the error, they are type correct modulo dominance. Sounds good to me.

test/langtools/tools/javac/patterns/NewCaseStructureTest.java

+                       return switch (o) {
+                           case E e when e == E.A -> 0;
+                           case B -> 0;
+                           case E e -> 0;


test/langtools/tools/javac/patterns/NewCaseStructureTest.java

+                       return switch (o) {
+                           default -> 0;
+                           case (Integer i) when i > 0 -> 0;
+                           case (Integer i) when i > 0 -> 0;


test/langtools/tools/javac/patterns/NewCaseStructureTest.java

+               public class Test {
+                   private int test(Integer o) {
+                       return switch (o) {
+                           case (Integer i) when i > 0 -> 0;


test/langtools/tools/javac/patterns/NewCaseStructureTest.java

+                       return switch (o) {
+                           case String s when s.isEmpty() -> 0;
+                           case "a" -> 0;
+                           case String s -> 0;


biboudis · 2022-10-25T13:31:07Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java

@@ -651,6 +652,81 @@ public Type instantiateFunctionalInterface(DiagnosticPosition pos, Type funcInte
            return owntype;
        }
    }
+
+    public Type instantiatePatternType(DiagnosticPosition pos, Type expressionType, TypeSymbol patternTypeSymbol) {


pos seems unused so far.

mlbridge · 2022-10-30T18:52:31Z

Webrevs

mcimadamore · 2022-11-01T12:31:07Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java

+                undet.setInst(bounds.head);
+            } else {
+                List<Type> upperBounds = undet.getBounds(InferenceBound.UPPER);
+                Type bound = upperBounds.isEmpty() ? syms.objectType : types.glb(upperBounds);


I'm not sure this is 100% correct. E.g. what if an under variable has an upper bound that refers to itself - e.g. T <: Foo<T>. In this case we need to step - first create the new tvars, then replace new tvars in the bound of the old ones. We do this in Infer::instantiateAsUninferredVars - perhaps some code from there should be borrowed?

mcimadamore · 2022-11-01T12:33:15Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java

+        capturedWildcards.forEach(s -> ((UndetVar) c.asUndetVar(s)).setNormal());
+
+        //step 2:
+        Set<Symbol> patternTypeSuperTypes = new HashSet<>();


Can you use Infer::getParameterizedSupers for this?

mcimadamore · 2022-11-01T12:37:48Z

test/langtools/tools/javac/patterns/InferenceUnitTest.java

+        checkAsSub("A<T1>", "B", "B<T1>");
+    }
+
+    private void checkAsSub(String base, String test, String expected) {


maybe change the name of this function, since Types::asSub is no longer used

mcimadamore

Looks good - left some minor comments

src/jdk.compiler/share/classes/com/sun/source/tree/InstanceOfTree.java

mcimadamore · 2022-11-07T09:02:56Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java

            List<Type> bounds = InferenceStep.EQ.filterBounds(undet, c);
            if (bounds.nonEmpty()) {
                undet.setInst(bounds.head);
            } else {
                List<Type> upperBounds = undet.getBounds(InferenceBound.UPPER);
-                Type bound = upperBounds.isEmpty() ? syms.objectType : types.glb(upperBounds);
+                Type bound;


Maybe we should call this upper, for uniformity

Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore@users.noreply.github.com>

vicente-romero-oracle · 2022-11-09T04:32:44Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java

+        Type patternType = c.asUndetVar(patternTypeSymbol.type);
+        Type exprType = c.asUndetVar(expressionTypeCaptured);
+
+        capturedWildcards.forEach(s -> ((UndetVar) c.asUndetVar(s)).setNormal());


could be a minor issue but still: it doesn't feel correct to set an UndetVar created from a captured type as normal. I think that we should either create a TypeVar with the info from the CapturedType and then create a normal UndetVar with that TypeVar or we should create another category inside enum Kind:

enum Kind { NORMAL, CAPTURED, THROWS; }

MODIFIABLE_CAPTURED dunno, just my opinion

vicente-romero-oracle · 2022-11-09T05:22:24Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java

+
+        try {
+            //step 2:
+            if (commonSuperWithDiffParameterization(patternType, exprType)) {


I think this is not correct according to the spec. The spec says:

If T' is a parameterization of a generic class G, and there exists a supertype of R<α1, ..., αn> that is also a parameterization of G, let R' be that supertype...

the current code could look for any common supertype even if that common supertype is not G but a super type of G that is also common to R. More than that the current code will look for all common parameterized supertypes and create bonds etc. I think the right thing to do here according to the spec is:

if (!types.isSameType(types.asSuper(patternType, exprType.tsym), exprType)) { return null; }

unless I'm missing something here

vicente-romero-oracle · 2022-11-09T06:16:36Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java

+
+            doIncorporation(c, types.noWarnings);
+
+            while (c.solveBasic(varsToSolve, EnumSet.of(InferenceStep.EQ)).nonEmpty()) {


if varsToSolve is equal to the number of variables in the inference context this step is a no-op and I think this should be always the case, so I think that the real resolution is happening below when instantiatePatternVars is invoked, unless I'm missing something this while loop could be safely removed

vicente-romero-oracle · 2022-11-09T16:22:35Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java

@@ -651,6 +654,90 @@ public Type instantiateFunctionalInterface(DiagnosticPosition pos, Type funcInte
            return owntype;
        }
    }
+


nit: before we push this I think some javadoc, not too formal mostly for ourselves, should be added explaining what this method is doing etc, now we remember but later on we could forget some details, also a reference to the section of the spec will be very helpful

vicente-romero-oracle · 2022-11-09T18:07:58Z

side: I extracted this example from the spec:

import java.util.function.*;

record Mapper<T>(T in, T out) implements UnaryOperator<T> {
    public T apply(T arg) { return in.equals(arg) ? out : null; }
}


class Test {
    void test(Function<? super String, ? extends CharSequence> f) {
        if (f instanceof Mapper(var in, var out)) {
            boolean shorter = out.length() < in.length();
        }
    }
}

it is not accepted by the current code, we should either modify the spec or go deeper and see if there is something missing in the current implementation

vicente-romero-oracle · 2022-11-09T19:48:01Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java

@@ -651,6 +654,90 @@ public Type instantiateFunctionalInterface(DiagnosticPosition pos, Type funcInte
            return owntype;
        }
    }
+
+    public Type instantiatePatternType(Type expressionType, TypeSymbol patternTypeSymbol) {
+        if (expressionType.tsym == patternTypeSymbol)


not sure we are dealing with cases where expressionType is a type variable or an intersection type, are there tests covering these cases, sorry if I'm missing something here

Good catch, thanks! Should be fixed in 5afc602. Thanks!

vicente-romero-oracle · 2022-11-09T20:28:14Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java

+        ListBuffer<Type> todo = new ListBuffer<>();
+
+        //step 1 - create fresh tvars
+        for (Type t : vars) {


I'm not sure about this so just a question: shouldn't we run this loop until no more undetVars need to be instantiated? we could also limit until a maximum number of steps in case we find cases that doesn't converge to a solution

In my understanding, we are not creating new undet vars here, and we instantiate them all in this loop, and fix their bounds if needed in the next step, so this should resolve all the vars.

ok, yes I guess we should be fine and if we find any issue in the future we can always go back and react then

…ction types.

vicente-romero-oracle · 2022-11-15T15:56:31Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java

+                    }
+                }
+                case TYPEVAR -> {
+                    todo = todo.prepend(((TypeVar) current).getUpperBound());


here you probably want to skip all possible upper bounds that happen to be type vars using Types::skipTypeVars

vicente-romero-oracle

I just added a nit comment. Really nice job, very complex patch, lots of details and moving parts, very vertical also with mostly all phases affected adding to the complexity, lots of fun to reviewed it too. Well done!

openjdk · 2022-11-16T03:41:19Z

@lahodaj This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8294942: Compiler implementation for Record Patterns (Second Preview)
8294945: Compiler implementation for Pattern Matching for switch (Fourth Preview)

Co-authored-by: Aggelos Biboudis <abimpoudis@openjdk.org>
Co-authored-by: Maurizio Cimadamore <mcimadamore@openjdk.org>
Reviewed-by: mcimadamore, vromero

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 23 new commits pushed to the master branch:

301cf52: 8297284: ResolutionErrorTable's key is wrong
a97e7d9: 8297740: runtime/ClassUnload/UnloadTest.java failed with "Test failed: should still be live"
4d730f5: 8297644: RISC-V: Compilation error when shenandoah is disabled
27b339d: 8297523: Various GetPrimitiveArrayCritical miss result - NULL check
3f8882b: 8297693: Fix typos in src/hotspot and test/hotspot files
b52611b: 8295401: Error recovery in module-info.java could be improved
9e80cf9: 8296390: Incremental build failed with a NPE
b3501fd: 8297600: Check current thread in selected JRT_LEAF methods
f05bfb1: 8297515: serialVersionUID fields are not annotated with @serial
22f5d01: 8252584: HotSpot Style Guide should permit alignas
... and 13 more: https://git.openjdk.org/jdk/compare/7af6b4b54cc2ead4f5dbd6bfa7fd343b84c1d8b5...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

lahodaj · 2022-11-21T13:51:58Z

/issue JDK-8294945

openjdk · 2022-11-21T13:52:45Z

@lahodaj
Adding additional issue to issue list: 8294945: Compiler implementation for Pattern Matching for switch (Fourth Preview).

lahodaj · 2022-11-21T13:52:48Z

/contributor abimpoudis

lahodaj · 2022-11-21T13:53:27Z

/contributor mcimadamore

openjdk · 2022-11-21T13:54:02Z

@lahodaj this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8294942
git fetch https://git.openjdk.org/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

openjdk · 2022-11-21T13:54:35Z

@lahodaj Syntax: /contributor (add|remove) [@user | openjdk-user | Full Name <email@address>]. For example:

/contributor add @openjdk-bot
/contributor add duke
/contributor add J. Duke <duke@openjdk.org>

User names can only be used for users in the census associated with this repository. For other contributors you need to supply the full name and email address.

openjdk · 2022-11-21T13:54:57Z

@lahodaj Syntax: /contributor (add|remove) [@user | openjdk-user | Full Name <email@address>]. For example:

/contributor add @openjdk-bot
/contributor add duke
/contributor add J. Duke <duke@openjdk.org>

User names can only be used for users in the census associated with this repository. For other contributors you need to supply the full name and email address.

lahodaj · 2022-11-21T13:55:02Z

/contributor add abimpoudis

openjdk · 2022-11-21T13:55:15Z

@lahodaj
Contributor Aggelos Biboudis <abimpoudis@openjdk.org> successfully added.

lahodaj · 2022-11-21T17:47:38Z

/contributor add mcimadamore

openjdk · 2022-11-21T17:48:54Z

@lahodaj
Contributor Maurizio Cimadamore <mcimadamore@openjdk.org> successfully added.

lahodaj · 2022-12-01T08:00:47Z

/integrate

openjdk · 2022-12-01T08:02:53Z

Going to push as commit 756dd5b.
Since your change was applied there have been 39 commits pushed to the master branch:

c612512: 8296660: Swing HTML table with omitted closing tags misparsed
56048f9: 8297852: Backout 8252584 for the time being
f49acd5: 8297697: RISC-V: Add support for SATP mode detection
3b513a4: 8297802: display of @SPEC tags should mimic that of @see tags
4485d4e: 8297728: Cache invocation type rather than invoker in NamedFunction
e9d501e: 8297519: Improve expressions and modernise code in PKCS
1722f9c: 8290231: java/foreign/malloc/TestMixedMallocFree.java crashed in JDK19 ATR run
1a2ff58: 8297736: test/jdk/java/foreign/TestMatrix.java is broken
6bac332: 8297853: windows-x86 test build broken
53dd214: 8297742: Combine vmTestbase/nsk/monitoring/ThreadMXBean/resetPeakThreadCount tests
... and 29 more: https://git.openjdk.org/jdk/compare/7af6b4b54cc2ead4f5dbd6bfa7fd343b84c1d8b5...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-12-01T08:03:19Z

@lahodaj Pushed as commit 756dd5b.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8294942: Compiler implementation for Record Patterns (Second Preview)

a17ec69

openjdk bot added the csr Pull request needs approved CSR before integration label Oct 21, 2022

openjdk bot added the compiler compiler-dev@openjdk.org label Oct 21, 2022

biboudis reviewed Oct 25, 2022

View reviewed changes

lahodaj added 4 commits October 30, 2022 08:57

Various cleanup and adjustments to specification updates.

2f0c597

Some more cleanup.

9b0bd99

Cleanup.

456e811

Fixing test.

6f1c30d

lahodaj marked this pull request as ready for review October 30, 2022 18:47

openjdk bot added the rfr Pull request is ready for review label Oct 30, 2022

openjdk bot mentioned this pull request Oct 31, 2022

8294943: Implement record patterns in enhanced for #10798

Closed

3 tasks

mcimadamore reviewed Nov 1, 2022

View reviewed changes

lahodaj added 3 commits November 4, 2022 10:03

Reflecting review feedback.

f68756f

Adding a kind to InstanceOfTree, as suggested.

efe0d21

Better tests for inference with recursive bounds, and related fixes.

77c34fc

mcimadamore approved these changes Nov 7, 2022

View reviewed changes

lahodaj and others added 2 commits November 7, 2022 11:42

Apply suggestions from code review

89e28ab

Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore@users.noreply.github.com>

Reflecting review comment.

c8f29c4

vicente-romero-oracle reviewed Nov 9, 2022

View reviewed changes

Not looking for common supertype, not solving in a loop.

5996914

vicente-romero-oracle reviewed Nov 9, 2022

View reviewed changes

Reflecting review feedback - proper handling of type vars and interse…

5afc602

…ction types.

vicente-romero-oracle reviewed Nov 15, 2022

View reviewed changes

vicente-romero-oracle approved these changes Nov 15, 2022

View reviewed changes

Using skipTypeVars as suggested.

e7196a0

openjdk bot removed the csr Pull request needs approved CSR before integration label Nov 16, 2022

openjdk bot added the ready Pull request is ready to be integrated label Nov 16, 2022

openjdk bot mentioned this pull request Nov 16, 2022

8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions #11189

Closed

4 tasks

openjdk bot added merge-conflict Pull request has merge conflict with target branch and removed ready Pull request is ready to be integrated labels Nov 21, 2022

Merge branch 'master' into JDK-8294942

5e8e554

openjdk bot added ready Pull request is ready to be integrated and removed merge-conflict Pull request has merge conflict with target branch labels Nov 23, 2022

Merge branch 'master' into JDK-8294942

4d01e00

openjdk bot added the integrated Pull request has been integrated label Dec 1, 2022

openjdk bot closed this Dec 1, 2022

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Dec 1, 2022


		doIncorporation(c, types.noWarnings);

		while (c.solveBasic(varsToSolve, EnumSet.of(InferenceStep.EQ)).nonEmpty()) {

8294942: Compiler implementation for Record Patterns (Second Preview) #10814

8294942: Compiler implementation for Record Patterns (Second Preview) #10814

Conversation

lahodaj commented Oct 21, 2022 • edited by openjdk bot Loading

Progress

Issues

Reviewers

Contributors

Reviewing

bridgekeeper bot commented Oct 21, 2022

openjdk bot commented Oct 21, 2022

biboudis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

Choose a reason for hiding this comment

mlbridge bot commented Oct 30, 2022 • edited Loading

Webrevs

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mcimadamore left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vicente-romero-oracle Nov 9, 2022 • edited Loading

Choose a reason for hiding this comment

vicente-romero-oracle commented Nov 9, 2022 • edited Loading

vicente-romero-oracle Nov 9, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vicente-romero-oracle Nov 14, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vicente-romero-oracle left a comment

Choose a reason for hiding this comment

openjdk bot commented Nov 16, 2022 • edited Loading

lahodaj commented Nov 21, 2022

openjdk bot commented Nov 21, 2022

lahodaj commented Nov 21, 2022

lahodaj commented Nov 21, 2022

openjdk bot commented Nov 21, 2022

openjdk bot commented Nov 21, 2022

openjdk bot commented Nov 21, 2022

lahodaj commented Nov 21, 2022

openjdk bot commented Nov 21, 2022

lahodaj commented Nov 21, 2022

openjdk bot commented Nov 21, 2022

lahodaj commented Dec 1, 2022

openjdk bot commented Dec 1, 2022

openjdk bot commented Dec 1, 2022

lahodaj commented Oct 21, 2022 •

edited by openjdk bot

Loading

mlbridge bot commented Oct 30, 2022 •

edited

Loading

vicente-romero-oracle Nov 9, 2022 •

edited

Loading

vicente-romero-oracle commented Nov 9, 2022 •

edited

Loading

vicente-romero-oracle Nov 9, 2022 •

edited

Loading

vicente-romero-oracle Nov 14, 2022 •

edited

Loading

openjdk bot commented Nov 16, 2022 •

edited

Loading