-
Notifications
You must be signed in to change notification settings - Fork 88
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
refactor(tests): confirm migration of EOF rjump tests #1031
base: main
Are you sure you want to change the base?
Conversation
5f149f9
to
5b11203
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.
Copilot reviewed 4 out of 5 changed files in this pull request and generated no comments.
Files not reviewed (1)
- converted-ethereum-tests.txt: Language not supported
5b11203
to
6c18a1f
Compare
6c18a1f
to
1728142
Compare
data=Container( | ||
sections=[Section.Code(code=Op.RJUMP + Op.STOP)], | ||
), | ||
data=Container.Code(Op.RJUMP + Op.STOP), |
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.
Not wild about this notation for a truncated instruction tests as it implies an opcode, but truncation tests are about broken conventions anyway, so I'll not complain too loundly.
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.
What is good replacement? Op.RJUMP + "00"
?
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.
It did cause confusion for me at first glance. What about allowing arbitrary data portions with when argument in the square brackets is already a bytes-like object. E.g.
Op.RJUMP[0]
->0xef0000
Op.RJUMP[b"\0"]
->0xef00
Op.RJUMP[b""]
->0xef
Not for this PR anyway because I'm not sure how many tests such a change would break.
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.
Fine to me.
Allowing verbatim hex in the code is also good to me. E.g. we sometimes need to use undefined opcodes.
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.
verbatim hex is great. bytes-like as literal args is also good.
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 works currently: Op.RJUMP + Bytecode(b"\x00")
. Should I change it?
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.
Op.RJUMP + Bytecode(b"\x00")
Yes I think this is our best choice at the moment.
Separately, I'm going to prepare the PR to allow verbatim bytes, but it's going to take me a bit to make sure it does not break existing tests.
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.
Ok. I will update these tests with Bytecode(b"\x00")
.
I can also try the separate PR mentioned. Is this about overloading +
operator?
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.
Ah, actually the Bytecode(b"\x00")
is broken because Bytecode tries to read some metadata of the argument.
What works is: bytes(Op.RJUMP) + b"\x00"
?
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.
LGTM, thanks for the changes!
data=Container( | ||
sections=[Section.Code(code=Op.RJUMP + Op.STOP)], | ||
), | ||
data=Container.Code(Op.RJUMP + Op.STOP), |
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.
It did cause confusion for me at first glance. What about allowing arbitrary data portions with when argument in the square brackets is already a bytes-like object. E.g.
Op.RJUMP[0]
->0xef0000
Op.RJUMP[b"\0"]
->0xef00
Op.RJUMP[b""]
->0xef
Not for this PR anyway because I'm not sure how many tests such a change would break.
@@ -609,7 +503,7 @@ def test_rjump_into_eofcreate( | |||
data=Container( | |||
sections=[ | |||
Section.Code( | |||
code=Op.RJUMP[1] + Op.EOFCREATE[0](0, 0, 0, 0) + Op.STOP, | |||
code=Op.PUSH0 * 4 + Op.RJUMP[1] + Op.EOFCREATE[0] + Op.STOP, |
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, I think this makes more 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.
It was actually a bug. Previously it jumped to the first PUSH data before EOFCREATE. Also jumping over PUSHes changes stack height. But the main issue is that it is hard to tell that (0, 0, 0, 0)
are actually 4 PUSH1 instructions. And maybe they will be changed to PUSH0 in some future update?
There are similar tests for RJUMPI and RJUMPV but without a bug. Should I got and change them too?
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 I think it's a good opportunity, this is simply a much better approach, and it's much more resilient too.
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.
Done.
The EOF validation tests related to rjumps (EIP-4200) are already here. This change confirms the migration is completed and updates the EOF test tracker. There is some additional refactoring done in the tests to trigger the test coverage CI job.
1728142
to
081bacb
Compare
data=Container( | ||
sections=[Section.Code(code=Op.RJUMP + Op.STOP)], | ||
), | ||
data=Container.Code(Op.RJUMP + Op.STOP), |
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.
Op.RJUMP + Bytecode(b"\x00")
Yes I think this is our best choice at the moment.
Separately, I'm going to prepare the PR to allow verbatim bytes, but it's going to take me a bit to make sure it does not break existing tests.
🗒️ Description
The EOF validation tests related to rjumps (EIP-4200) are already here. This change confirms the migration is completed and updates the EOF test tracker.
There is some additional refactoring done in the tests to trigger the test coverage CI job.
✅ Checklist
mkdocs serve
locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.