New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8273328: Compiler implementation for Pattern Matching for switch (Second Preview) #6209
Conversation
|
@lahodaj This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
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 237 new commits pushed to the
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.
|
Looks good. Left one comment about the logic in Flow.
@@ -784,7 +784,7 @@ private void transitiveCovers(Set<Symbol> covered) { | |||
} | |||
} | |||
|
|||
private boolean isTransitivelyCovered(Symbol sealed, Set<Symbol> covered) { | |||
private boolean isTransitivelyCovered(Type seltype, Symbol sealed, Set<Symbol> covered) { | |||
DeferredCompletionFailureHandler.Handler prevHandler = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to guard against completion failures here in Flow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider a case like this:
sealed interface I permits A, B {}
//A and B defined
...
I i = null;
switch (i) {
case A -> {}
}
This will produce an error, because the switch is not exhaustive. Now, consider, in addition, that B
is missing. It feels a bit harsh to produce an error about the missing B
permitted subclass (possibly producing that error instead of the exhaustiveness error), as it seems plausible permitted subclasses may be missing during compilation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhm - I get what you say. But isn't sealing meant to be used within a single maintenance domain? If B is missing, how the heck did we get to Flow in the first place (since for sealed classes we check that permitted subclasses extend the sealed class being defined)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhm - I get what you say. But isn't sealing meant to be used within a single maintenance domain? If B is missing, how the heck did we get to Flow in the first place (since for sealed classes we check that permitted subclasses extend the sealed class being defined)
Ok - maybe you are considering the case where I
is used in a compilation unit which did not defined it. And which cannot (for some reason) see B. Seems cornery, but what I'm mostly worried about is that it's not (I think) uniform with the rest of the javac code dealing with sealed classes. For instance, look at the cast conversion rules in Types::areDisjoint
- in that case there's no protection against missing types.
I think the compiler code should be consistent in how we reason about sealed permitted types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, the case is where the sealed class/interface is used from some other project. It is somewhat cornery, but might happen even for us - consider an sealed API interface in the JDK, which has permitted classes that are in an implementation package. The --release
data normally do not include non-API packages, so when looking at the API interface, we may encounter a class that does not exist.
I didn't realize there is the same issue with areDisjoint
, but you are right it suffers from the problem and that it should be consistent. I'll take a look at that, possibly separately, if that's OK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep - fine to postpone!
/csr needed |
@lahodaj this pull request will not be integrated until the CSR request JDK-8275408 for issue JDK-8273328 has been approved. |
/integrate |
Going to push as commit d085c2b.
Your commit was automatically rebased without conflicts. |
The specification for pattern matching for switch (preview)[1] has been updated with two changes:
-any type of pattern (including guarded patterns) dominates constant cases. Dominance across pattern/non-constant cases is unchanged. (See the change in
Attr.java
.)-for sealed hierarchies, it may happen some of the subtypes are impossible (not castable) to the selector type. Like, for example:
But, the exhaustiveness checks in JDK 17 required all the permitted subclasses, including
A
, are covered by the switch, which forced adefault
clause in place ofcase A a
for cases like this. The updated specification excludes such impossible permitted subclasses from exhaustiveness checks, so the default is no longer needed and this:compiles OK.
(See the change in
Flow.java
.)[1] http://cr.openjdk.java.net/~gbierman/jep420/jep420-20211020/specs/patterns-switch-jls.html
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6209/head:pull/6209
$ git checkout pull/6209
Update a local copy of the PR:
$ git checkout pull/6209
$ git pull https://git.openjdk.java.net/jdk pull/6209/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 6209
View PR using the GUI difftool:
$ git pr show -t 6209
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6209.diff