-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8200145: Conditional expression mistakenly treated as standalone #2324
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
👋 Welcome back lgxbslgx! A progress list of the required criteria for merging this PR into |
Webrevs
|
@lgxbslgx This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
I think we want to ping @lahodaj to see if this makes sense. |
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 fix looks good - it's a good "quality of life" fix, which improves the conditional classification by making it more resilient to erroneous types. I wonder if the fix can be made more minimal (see code comment).
@@ -4323,6 +4323,8 @@ public Type boxedTypeOrType(Type t) { | |||
* Return the primitive type corresponding to a boxed type. | |||
*/ | |||
public Type unboxedType(Type t) { | |||
if (t.hasTag(ERROR)) |
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.
This is not necessary, right? After all, you check for errors upfront, in the conditional code. Reason I'm asking is that it's not clear to me as to whether we should just return the error type, or no type. Also, this might affect code which is unrelated to the one you are fixing.
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 am not an expert on types, so I may be wrong.)
This method seems to return either the primitive type for which t
is a box, or noType
. So returning a noType
for erroneous type seems reasonable to me. Basically, it would mean that an erroneous type is not a box for any type, which seems sensible. (Currently, every erroneous type is seen as the box for the first primitive type in the sequence, which I think is byte
.)
I agree only one of these two changes is needed, although I'd personally probably try to go with the one here, in unboxedType
, as it seems like a generally desirable behavior to me. I agree it can have effects on other parts of the code, though, so it has more potential to break something.
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 ok with going for the proposed fix, as long as tests are ok. Approving.
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.
Yes, this is not necessary if we only solve this bug. But it is useful logically. And all the related tests passed locally and passed at the Pre-submit tests
. So I think it is good to remain it.
@@ -1956,7 +1956,7 @@ private boolean isBooleanOrNumeric(Env<AttrContext> env, JCExpression tree) { | |||
} | |||
//where | |||
boolean primitiveOrBoxed(Type t) { | |||
return (!t.hasTag(TYPEVAR) && types.unboxedTypeOrType(t).isPrimitive()); | |||
return (!t.hasTag(TYPEVAR) && !t.hasTag(ERROR) && types.unboxedTypeOrType(t).isPrimitive()); |
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.
Good catch - you can also use !t.isErroneous()
here.
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.
Fixed.
@lgxbslgx 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 no new commits pushed to 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 (@mcimadamore) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
/integrate |
I updated the code according to the comment. Thank you for reviewing again and sponsoring. /integrate |
@mcimadamore Could I get your help to re-review and sponsor? Thanks a lot. |
/sponsor |
@mcimadamore @lgxbslgx Since your change was applied there have been 63 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 07a7510. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Hi all,
If the argument
Type t
of the methodTypes.unboxedType
is anErrorType
, theTypes.unboxedType
may return the wrong result. And in this case,Attr.isBooleanOrNumeric
andAttr.isBooleanOrNumeric
return the wrong result, too.This patch fixes it and adds a test case.
Thank you for taking the time to review.
Best Regards.
-- xiong
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/2324/head:pull/2324
$ git checkout pull/2324
Update a local copy of the PR:
$ git checkout pull/2324
$ git pull https://git.openjdk.java.net/jdk pull/2324/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 2324
View PR using the GUI difftool:
$ git pr show -t 2324
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/2324.diff