-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
8332106: VerifyError when using switch pattern in this(...) or super(...) #19217
Conversation
👋 Welcome back jlahoda! A progress list of the required criteria for merging this PR into |
@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:
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 114 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. ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
import java.util.Objects; | ||
import java.util.function.Supplier; | ||
|
||
public class UninitializedThisException { |
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.
nit: It would be nice to have a test for super(...)
as well even though I am confident that it works. Feel free to ignore if there is no need for an extra test.
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.
Tests enahanced: 9dacde8
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.
LGTM
Set<JCMethodInvocation> invocationsWithPatternMatchingCatch = Set.of(); | ||
ListBuffer<int[]> patternMatchingInvocationRanges; | ||
PatternMatchingCatchConfigration patternMatchingCatchConfiguration = | ||
new PatternMatchingCatchConfigration(Set.of(), null, null, null); |
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.
typo: Configuration
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.
looks sensible
/integrate |
Going to push as commit af056c1.
Your commit was automatically rebased without conflicts. |
Considering code like:
Running this crashes:
The reason is that there is a synthetic catch generated wrapping the record accessors inside the pattern matching. The range where the exception this catch is catching is before the real
this(...)
invokespecial
, and hence thethis
is still an "uninitialized this". But the code for the catch is generated at the end of the constructor, whenthis
is already initialized, and javac generates the stack maps as ifthis
was initialized.In general, the pattern matching code can be both before and after the
this
has been initialized. But, I don't think a stack map frame can be generated for the handler originating in places with both "uninitialized this " and (initialized) this.The proposal here is to generate one set of the catch handlers for the state with "uninitialized this", and another for (initialized) this, if needed.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19217/head:pull/19217
$ git checkout pull/19217
Update a local copy of the PR:
$ git checkout pull/19217
$ git pull https://git.openjdk.org/jdk.git pull/19217/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 19217
View PR using the GUI difftool:
$ git pr show -t 19217
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19217.diff
Webrev
Link to Webrev Comment