accounts/abi refactor#15731
Conversation
Event.tupleUnpack doesn't handle correctly Indexed arguments, hence it can't unpack an event with indexed arguments.
+ The event slice unpacker doesn't correctly extract element from the slice. The indexed arguments are not ignored as they should be (the data offset should not include the indexed arguments). + The `Elem()` call in the slice unpack doesn't work. The Slice related tests fails because of that. + the check in the loop are suboptimal and have been extracted out of the loop. + extracted common code from event and method tupleUnpack
+ adding missing comments + small cleanups which won't significantly change function body. + unify Method receiver name
+ Reworked Method Unpack tests into more readable components + Added Method Unpack into slice test
|
To the people on cc: I have done my best to ensure that the functionality of the preceding PR:s in this package has been kept intact, but if I've messed with anything, please yell. |
|
Why we are redoing this changes instead of merging long hanging PR (around 2 months already) and then updating? |
|
@robert-zaremba it's not "redone", if you look at it your PR has been integrated into this one. |
The reason is that we started merging a couple of PR:s in that section, which made your PR conflict. So we had to fix it up. Since I did not want to get stuck waiting for someone to fix it, I did it myself (at the same time that @gballet was also doing it), and then rebased my pr on top of your commits. So I've spent quite some time to ensure that everyone gets credit (commits) and that all functionality is intact. Now, in hindsight, I should've/could've the rebased version of you PR back into your PR... But as I noticed halfway through that @gballet was also rebasing that one, it seemed like quite a tangle. |
|
@holiman |
There was a problem hiding this comment.
Do we need to return a pointer? It's a small structure. How about returning (Method, bool)?
There was a problem hiding this comment.
Well, that would work too... Don't know why that would be better really...
There was a problem hiding this comment.
How about using testify?
6 lines above could be substituted with:
require.True
require.Equal
Also this solves another issue: if the first if fails then the second one shouldn't be executed.
There was a problem hiding this comment.
I haven't gotten used to testify yet, that's the reason :)
I'll keep it in mind for future reference
There was a problem hiding this comment.
you can use testify:
require.NoError
There was a problem hiding this comment.
comment should be removed
There was a problem hiding this comment.
you don't need this if. for will handle empty / nil slice
gballet
left a comment
There was a problem hiding this comment.
Minor nitpicks. Great cleanup!
There was a problem hiding this comment.
Couldn't there be a lookup table for method.Id() <=> method ?
There was a problem hiding this comment.
There could be, but I don't think this will be extensively used; I'll use it from the signer, but it's a one-off operation. So might as well do it lazily.
There was a problem hiding this comment.
Some linters will complain if there is no consistency when implementing methods for a type. I advise that you call all methods arguments instead of a
|
Travis failures unrelated: Go 1.7.x: |
|
I pushed some fixes to the comments, thanks for reviewing! |
|
Squashed for niceness |
This PR changes the ABI-model, since ABI is an encoding of arguments, the unpack logic has been moved away from
Method/Event, and on to the new typeArguments(alias for[]Argument).This PR removes a lot of duplicated code and also makes it easier to unpack method inputs as well as outputs, and also simplifies the logic in the abi-package.
This PR also incorporates (and supersedes) #15452 , with some extra testcases taken from #15568 .
This is a large PR, but I believe the abi-package to be fairly well covered by testcases at this point.