-
-
Notifications
You must be signed in to change notification settings - Fork 822
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
feat: add abi_decode builtin #2882
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2882 +/- ##
==========================================
+ Coverage 87.96% 88.04% +0.08%
==========================================
Files 95 95
Lines 10389 10435 +46
Branches 2502 2511 +9
==========================================
+ Hits 9139 9188 +49
+ Misses 794 790 -4
- Partials 456 457 +1
Continue to review full report at Codecov.
|
This pull request introduces 1 alert when merging 893cd1e into dcf65b6 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging 769a4b7 into 687ef4a - view on LGTM.com new alerts:
|
we also need a |
Co-authored-by: El De-dog-lo <3859395+fubuloubu@users.noreply.github.com>
This pull request introduces 1 alert when merging 1097b83 into 6b4d8ff - view on LGTM.com new alerts:
|
"len,output_typ,input", | ||
[ | ||
(160, "DynArray[uint256, 3]", b""), | ||
(160, "DynArray[uint256, 3]", b"\x01" * 192), |
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.
hmm, i think this fails because of the input arg clamper, not because of the clamper in abi_decode
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.
but maybe we can't actually hit the upper bound clamper?
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.
oh, and because the typechecker prevents the input arg from exceeding the upper bound as well?
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.
right, because we already check bytearray_len <= 160
when we deserialize the function args
@pytest.mark.parametrize( | ||
"len,output_typ1,output_typ2,input", | ||
[ | ||
(192, "DynArray[uint256, 3]", "uint256", b""), | ||
(192, "DynArray[uint256, 3]", "int128", b"\x01" * 224), |
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 think we should still have these test cases
(160, "DynArray[uint256, 3]", b""), | ||
(160, "DynArray[uint256, 3]", b"\x01" * 192), | ||
(96, "Bytes[5]", b""), | ||
(96, "Bytes[5]", b"\x01" * 128), |
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 now fails for the wrong reason - 128 > 96.
fail at decoding, not argument deserialization also rename some variables which shadow python builtins: len -> len_, input -> input_
What I did
Add
_abi_decode
builtin.TupleDefinition
toget_type_from_annotation
How I did it
Add
_abi_decode
to builtin functions module.How to verify it
See new tests
Commit message
Description for the changelog
Add
_abi_decode
builtin.Cute Animal Picture