-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8302344: Compiler Implementation for Unnamed patterns and variables (Preview) #13528
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
Conversation
…arse errors when deconstructing a record using the enhanced for loop of JEP 432" This reverts commit 2cb64a7
…parenthesized-patterns
# Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java # src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
|
||
/** | ||
* analyzeParens() has already classified the lambda as EXPLICIT_LAMBDA, due to |
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.
Many thanks for adding these precious comments!
reduce(LambdaParameterKind.IMPLICIT); | ||
return; |
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.
could we use if/else if/else and get rid of return?
|
||
/** | ||
* analyzeParens() has already classified the lambda as EXPLICIT_LAMBDA, due to | ||
* two consecutive identifiers. adding an erroneous parameter (one that |
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.
Shouldn't the second sentence say something more like:
Because of that (<explicit lambda>), the parser will always attempt to parse a type, followed by a name.
If the lambda contains an illegal mix of implicit and explicit parameters, it is possible for the parser to see a `,` when expecting a name, in which case the variable is created with an erroneous name.
The logic below makes sure that the lambda parameters are all declared with either an explicit type (e.g. `String x`), or with an inferred type (using `var x`).
Any other combination is rejected.
Thank you for the review @mcimadamore. I have also improved error reporting a bit; in the case |
# Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
The parent pull request that this pull request depends on has now been integrated and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout unnamed
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push |
@biboudis 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 4 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@vicente-romero-oracle, @jddarcy) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
/integrate |
/sponsor |
Going to push as commit 8aa5028.
Your commit was automatically rebased without conflicts. |
This PR implements JEP 443, the preview feature for Unnamed Patterns and Variables in Java.
Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
Progress
Issues
Reviewers
Contributors
<jlahoda@openjdk.org>
<abimpoudis@openjdk.org>
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528
$ git checkout pull/13528
Update a local copy of the PR:
$ git checkout pull/13528
$ git pull https://git.openjdk.org/jdk.git pull/13528/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 13528
View PR using the GUI difftool:
$ git pr show -t 13528
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13528.diff
Webrev
Link to Webrev Comment