Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

chfast
Copy link
Member

@chfast chfast commented Dec 18, 2024

🗒️ 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

  • All: Set appropriate labels for the changes.
  • All: Considered squashing commits to improve commit history.
  • All: Added an entry to CHANGELOG.md.
  • All: Considered updating the online docs in the ./docs/ directory.
  • Tests: All converted JSON/YML tests from ethereum/tests have been added to converted-ethereum-tests.txt.
  • Tests: A PR with removal of converted JSON/YML tests from ethereum/tests have been opened: remove migrated EOF RJUMP validation tests tests#1421
  • Tests: Included the type and version of evm t8n tool used to locally execute test cases: e.g., ref with commit hash or geth 1.13.1-stable-3f40e65.
  • Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.

@chfast chfast added scope:tests Scope: Test cases type:test Type: Test labels Dec 18, 2024
@chfast chfast force-pushed the eof/migrate_rjumps branch 2 times, most recently from 5f149f9 to 5b11203 Compare December 18, 2024 22:25
@chfast chfast requested a review from Copilot December 18, 2024 22:26

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
@chfast chfast marked this pull request as ready for review December 18, 2024 22:29
@chfast chfast force-pushed the eof/migrate_rjumps branch from 5b11203 to 6c18a1f Compare December 19, 2024 07:59
@chfast chfast force-pushed the eof/migrate_rjumps branch from 6c18a1f to 1728142 Compare December 19, 2024 15:05
@chfast chfast requested review from shemnon and marioevz December 19, 2024 15:19
data=Container(
sections=[Section.Code(code=Op.RJUMP + Op.STOP)],
),
data=Container.Code(Op.RJUMP + Op.STOP),
Copy link
Collaborator

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.

Copy link
Member Author

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"?

Copy link
Member

@marioevz marioevz Dec 19, 2024

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.

Copy link
Member Author

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.

Copy link
Collaborator

@shemnon shemnon Dec 19, 2024

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member Author

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"
?

Copy link
Member

@marioevz marioevz left a 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),
Copy link
Member

@marioevz marioevz Dec 19, 2024

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,
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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.
@chfast chfast force-pushed the eof/migrate_rjumps branch from 1728142 to 081bacb Compare December 19, 2024 18:16
data=Container(
sections=[Section.Code(code=Op.RJUMP + Op.STOP)],
),
data=Container.Code(Op.RJUMP + Op.STOP),
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope:tests Scope: Test cases type:test Type: Test
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants