Skip to content
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

Closed
wants to merge 10 commits into from

Conversation

mabbay
Copy link
Member

@mabbay mabbay commented Jul 4, 2024

Test Switch Expression lowering when case is constant.


Progress

  • Change must not contain extraneous whitespace

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

@bridgekeeper
Copy link

bridgekeeper bot commented Jul 4, 2024

👋 Welcome back mabbay! A progress list of the required criteria for merging this PR into code-reflection will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Jul 4, 2024

@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:

Test Switch Expression lowering when case is constant

Reviewed-by: mcimadamore

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 code-reflection branch:

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 code-reflection branch, type /integrate in a new comment.

return result != null ?
coerce(result, tree.type, target) :
null;
// there are cases where tree type is null
Copy link
Member Author

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 ?

Copy link
Collaborator

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 now
  • toValue(JCExpression) which delegates to toValue(expr, Type.noType)
  • toValue(JCStatement) which just call scan 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).

@openjdk openjdk bot added ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jul 4, 2024
@mlbridge
Copy link

mlbridge bot commented Jul 4, 2024

Webrevs

@mabbay mabbay self-assigned this Jul 12, 2024
@@ -15,112 +16,198 @@
*/
public class TestSwitchExpressionOp {

// TODO more testing
// cover cases where MatchException will be thrown
@Test
Copy link
Collaborator

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?

Copy link
Member Author

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 ?

Copy link
Collaborator

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.

Copy link
Member

@PaulSandoz PaulSandoz left a 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

@mabbay mabbay requested a review from mcimadamore July 24, 2024 20:30
}
()java.lang.String -> {
%7 : java.lang.String = constant @"BAR";
java.yield %7;
Copy link
Collaborator

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

Copy link
Member

@PaulSandoz PaulSandoz Aug 2, 2024

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 {
Copy link
Collaborator

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?

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Collaborator

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

@mabbay
Copy link
Member Author

mabbay commented Jul 29, 2024

/integrate

@openjdk
Copy link

openjdk bot commented Jul 29, 2024

Going to push as commit b4e13d5.
Since your change was applied there have been 14 commits pushed to the code-reflection branch:

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Jul 29, 2024
@openjdk openjdk bot closed this Jul 29, 2024
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jul 29, 2024
@openjdk
Copy link

openjdk bot commented Jul 29, 2024

@mabbay Pushed as commit b4e13d5.

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

@mabbay mabbay deleted the test-sw-lowering branch July 29, 2024 18:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

3 participants