Conversation
WalkthroughThis PR adds EOF (Extensible Opcode Format) bytecode detection and rejection throughout the extrospection library, updates EVM opcode handling by marking JUMP as halting and adding TSTORE to non-static operations, and refactors bytecode trimming with integrated EOF pre-checks. Comprehensive tests validate new EOF detection logic and existing scanning functionality. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
test/src/lib/LibExtrospectBytecode.trimSolidityCBORMetadata.t.sol (1)
27-61:⚠️ Potential issue | 🟡 MinorMissing EOF precondition in fuzz test.
The
testTrimSolidityCBORMetadataBytecodeContrivedfunction callstrimSolidityCBORMetadataat line 46, but unliketestTrimSolidityCBORMetadataBytecodeShort, it doesn't filter out EOF bytecode. If the fuzzer generates bytecode starting with0xEF00, the call will revert withEOFBytecodeNotSupported()instead of being skipped viavm.assume.Proposed fix
function testTrimSolidityCBORMetadataBytecodeContrived(bytes memory bytecode) external pure { + vm.assume(!LibExtrospectBytecode.isEOFBytecode(bytecode)); bytes32 a = keccak256(bytecode);
Motivation
Solution
Checks
By submitting this for review, I'm confirming I've done the following:
Summary by CodeRabbit
Release Notes
New Features
Tests