-
Notifications
You must be signed in to change notification settings - Fork 61
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
[v1] Fix unary minus with numeric literal parsing; add data exception for unary neg overflow #1718
Conversation
CROSS-ENGINE-REPORT ❌
Testing Details
Result Details
Now FAILING Tests ❌The following 7 test(s) were previously PASSING in BASE but are now FAILING in TARGET: Click here to see
Now IGNORED Tests ❌The complete list can be found in GitHub CI summary, either from Step Summary or in the Artifact. Now Passing Tests180 test(s) were previously failing in BASE (LEGACY-V0.14.8) but now pass in TARGET (EVAL-D60B65C). Before merging, confirm they are intended to pass. The complete list can be found in GitHub CI summary, either from Step Summary or in the Artifact. |
), | ||
// Make sure we parse Integer.MIN_VALUE as an INT rather than BIGINT |
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.
Can this work also have a test for the following: --${Integer.MIN_VALUE}
. This should fail.
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.
From my reading of the PR, this previously would fail and this might make it "pass" (though that would be wrong. If my assumption is correct, a different approach would be to update our ANTLR file instead.
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.
Can this work also have a test for the following:
--${Integer.MIN_VALUE}
. This should fail.
I assume you mean something like - -2147483648
? --${Integer.MIN_VALUE}
would be ---2147483648
which is parsed as a comment. Added.
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.
From my reading of the PR, this previously would fail and this might make it "pass" (though that would be wrong. If my assumption is correct, a different approach would be to update our ANTLR file instead.
The query - -2147483648
would actually pass previously and return back 2147483648
. - -2147483648
would get parsed as a two nested unary minuses with an unsigned INT_NUM literal 2147483648
(i.e. same thing as -(-(2147483648))
). This would get converted into the plan as a two nested unary neg with a big int value of 2147483648
, which evaluates to 2147483648
.
With this PR's change, - -2147483648
would now give the data exception. - -2147483648
now gets parsed as a single unary minus with a signed INT_NUM literal -2147483648
(i.e. same thing as -(-2147483648)
. Converting that into the plan would give a unary neg with a int value of -2147483648
, which will give an error when evaluated.
For the other comment about the ANTLR rule, I played around with this a while back with the literal modeling and couldn't seem get all the cases to parse correctly. For now, modifying it in the ANTLR visitor seems good enough but I added a TODO to look into it more in the future.
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.
Apologies. - - - 2147483648
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.
- - - 2147483648
Error behavior is the same as - - 2147483648
- both would fail in this PR
- previously, they would succeed.
- - - 2147483648
=>- 2147483648
and- - 2147483648
=>2147483648
I can add another test for regressions though
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.
- - - 2147483648
= -(-(-2147483648))
. Which, should fail. With the original commit, I believe this wouldn't fail. With your latest commit, I think it will fail 👍 . Though, a test would give me confidence.
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.
Yeah good catch, the original commit had a bug (should only add the -
sign to a literal numeric string if and only if there was no prior -
added).
Added the triple -
test in 7df4329
(#1718).
), | ||
// Make sure we parse Integer.MIN_VALUE as an INT rather than BIGINT |
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.
From my reading of the PR, this previously would fail and this might make it "pass" (though that would be wrong. If my assumption is correct, a different approach would be to update our ANTLR file instead.
7df4329
to
64961d4
Compare
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.
Nice work 🥇
Relevant Issues
Description
-2147483648
as an INT4License Information
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.