-
Notifications
You must be signed in to change notification settings - Fork 18
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
Test Switch Expression lowering when case is constant #169
Conversation
👋 Welcome back mabbay! A progress list of the required criteria for merging this PR into |
@mabbay 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 14 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 |
return result != null ? | ||
coerce(result, tree.type, target) : | ||
null; | ||
// there are cases where tree type is 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.
@mcimadamore what do you think about this ?
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.
In principle, this method should only be called for expressions. And all expressions have some type. I see two cases where this is not true:
- body of a switch label following a
->
which can be either an expression, or a throw (the latter is a statement, so it has no type) - the body of a lambda expression, which can be either a JCBlock (no type) or a JCExpression
It might perhaps be better to cleanup this code by making sure that we have the following methods:
toValue(JCExpression, Type)
, like the one we have nowtoValue(JCExpression)
which delegates totoValue(expr, Type.noType)
toValue(JCStatement)
which just callscan
on the statement (no target type and no conversion here)
Then, clients will have to pay attention to which method to call. For instance, in the case of a switch label, we'd have to check whether the body of the label is a throw
statement, and if so call the statement overload of toValue
(w/o a target type).
Webrevs
|
src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java
Show resolved
Hide resolved
@@ -15,112 +16,198 @@ | |||
*/ | |||
public class TestSwitchExpressionOp { | |||
|
|||
// TODO more testing | |||
// cover cases where MatchException will be thrown | |||
@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.
Shouldn't we add similar tests in the compiler (with the @IR
annotation) to check that the model generated by javac contains the expected conversions?
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.
You mean a test similar to caseConstantOtherKindsOfExpr
?
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.
You mean a test similar to
caseConstantOtherKindsOfExpr
?
At least something like that yes.
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 good, i agree with Maurizio to add language tests comparing the models
} | ||
()java.lang.String -> { | ||
%7 : java.lang.String = constant @"BAR"; | ||
java.yield %7; |
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.
unrelated: but I found the distinction between yield
and java.yield
a bit confusing...
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.
Indeed it is confusing. The core operation yield
means to yield a value from a body, where as the extended operation java.yield
models Java's yield
statement. Perhaps rename the former to body.yield
?
* @build CodeReflectionTester | ||
* @run main CodeReflectionTester SwitchExpressionTest2 | ||
*/ | ||
public class SwitchExpressionTest2 { |
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.
I'm a bit confused: the core of the fix is to add a conversion to the selector type is the case label is constant, right? But I don't see any conv
node anywhere in the test (except for a single one where an explicit cast is used). Is the new code exercised in this 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.
The core of the changes is to test switch expression when case is constant, in the process we found that we miss conversion of the constant to the the type of the selector expression, we added that. I agree that we should add tests that focus more on conversion.
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.
caseConstantThrow
shows how we are converting constant label to the selector expression's type.
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.
I see - I was looking for convert
but it's true that there are some unboxing conversions in there
/integrate |
Going to push as commit b4e13d5.
Your commit was automatically rebased without conflicts. |
Test Switch Expression lowering when case is constant.
Progress
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/babylon.git pull/169/head:pull/169
$ git checkout pull/169
Update a local copy of the PR:
$ git checkout pull/169
$ git pull https://git.openjdk.org/babylon.git pull/169/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 169
View PR using the GUI difftool:
$ git pr show -t 169
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/babylon/pull/169.diff
Webrev
Link to Webrev Comment