Add support for numeric invert operator #526
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cburgdorf
force-pushed
the
christoph/feat/unary_invert
branch
2 times, most recently
from
86889d9
to
6add282
Compare
g-r-a-n-t
approved these changes
Aug 31, 2021
| case("return_invert_i64.fe", &[int_token(4000000000)], int_token(-4000000001)), | ||
| case("return_invert_i32.fe", &[int_token(30000)], int_token(-30001)), | ||
| case("return_invert_i16.fe", &[int_token(2000)], int_token(-2001)), | ||
| case("return_invert_i8.fe", &[int_token(1)], int_token(-2)), |
There was a problem hiding this comment.
Is there a special use for signed ints that I'm missing?
Since this is a bitwise operation, I think use should be restricted to unsigned ints, just like the binary bitwise operations.
There was a problem hiding this comment.
I haven't thought much about use cases but Solidity, Python, Rust (and probably other languages) all let you do this so I think we shouldn't be overly restrictive.
Solidity
int8 y = -10;
assert(~y == 9);Python:
>>> ~-10
9
Rust:
assert_eq!(!-10i8, 9);| let fn_name = names::adjust_numeric_size(&size); | ||
| function_definition! { | ||
| function [fn_name](value) -> cleaned { | ||
| (cleaned := signextend([literal_expression! { (base) }], value)) |
There was a problem hiding this comment.
Nice, this solution looks good.
There was a problem hiding this comment.
Just copied what Solidity is doing 😄 We still need to apply that to a bunch of other places (which I will follow up on after this PR)
g-r-a-n-t
reviewed
Aug 31, 2021
cburgdorf
force-pushed
the
christoph/feat/unary_invert
branch
from
6add282
to
4073cd4
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was wrong?
As noted in #521 we needed to add support for the
~operator which is currently recognized on the parser level but not analyzed and generates no code.How was it fixed?
Implementation is pretty straight forward. The more interesting part is that this PR lays the ground work for a bunch of new
adjust_numeric_*runtime functions that we need to use at a bunch more places to ensure numerics smaller than 256 bit are handled correctly. This PR only uses these methods for the unary invert operator.