Skip to content

feat(solidity-import): support Create2/Clones Yul address prediction, keccak256(_msgData()), and bounded deque pop while loops - #2502

Merged
Th0rgal merged 1 commit into
mainfrom
feat/solidity-import-slice-41
Oct 11, 2026
Merged

Th0rgal merged 1 commit into
mainfrom
feat/solidity-import-slice-41

Conversation

@Th0rgal

@Th0rgal Th0rgal commented Oct 11, 2026

Copy link
Copy Markdown
Member

Summary

  • Support OpenZeppelin 5.0 Create2.computeAddress(bytes32,bytes32,address) (7-statement Yul block hashing the 85-byte 0xff || deployer || salt || bytecodeHash window) and Clones.predictDeterministicAddress(address,bytes32,address) (8-statement Yul block hashing the 55-byte EIP-1167 runtime initcode at ptr..ptr+0x37 and then the 85-byte CREATE2 window at ptr+0x43..ptr+0x98).
  • Support zero-argument msg.data helpers returning bytes calldata or bytes memory (such as OpenZeppelin Context._msgData()) inside keccak256(_msgData()) and encoded byte contexts by materializing calldatasize bytes via calldatacopy.
  • Support bounded DoubleEndedQueue.Bytes32Deque popFront / popBack while loops (while (_governanceCall.popFront() != msgDataHash) {} and while (target != _backQueue.popBack()) {}) as used in OpenZeppelin GovernorTimelockControl.executeOperations.
  • Add Create2ClonesMsgDataDequeSequence.sol and Create2ClonesMsgDataDequeSequenceModel.lean, differential storage & stateful probes, rejection tests, and mutation anchors.

… keccak256(_msgData()), and bounded deque pop while loops
@Th0rgal
Th0rgal merged commit f40a74f into main Oct 11, 2026
@Th0rgal
Th0rgal deleted the feat/solidity-import-slice-41 branch October 11, 2026 20:38
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 11, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-11T20:40:18.932737Z 7705358 PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 770535816f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

unless ← isIdentNamed m8Args[0]! startName do return none
let some prefixByte ← yulNatLit? m8Args[1]! | return none
unless prefixByte < 256 do return none
let some (varNode, kStartNode, kSizeNode) ← keccakAssign? stmts[6]! | return none

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Unwrap the address mask before matching the hash

The OpenZeppelin blocks this branch is intended to support assign addr := and(keccak256(start, 85), 0xffff...ffff) (and Clones uses the same wrapper), as documented in docs/SOLIDITY_IMPORT.md:873-874. However, keccakAssign? only accepts an assignment whose RHS is directly a keccak256 call, so both real OpenZeppelin forms return none here and fall through to the generic lowering, which cannot handle this mload(0x40) block. The new positive fixture avoids the failure by omitting the and, so it does not exercise the advertised source form.

Useful? React with 👍 / 👎.

Comment on lines +9535 to +9539
unless fname == "popFront" || fname == "popBack" do return none
let params ← mArr (← mField (← mField fn "parameters") "parameters")
unless params.size == 1 && optStr params[0]! "storageLocation" == some "storage" do return none
let pty ← mType params[0]!
unless pty.startsWith "struct " && !pty.contains "[" do return none

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Verify deque pop semantics before imposing a bound

This recognizes any function named popFront or popBack with a storage struct whose first two fields have the expected names and types, without proving that the function advances the corresponding index or reverts when empty. For example, a custom library with the same struct shape and a popFront that always returns a nonmatching constant would loop until out-of-gas in Solidity, while this lowering computes a one-iteration bound for an empty deque and then continues execution. Either validate the admitted function body against the deque operation or restrict resolution to a known implementation before replacing the loop.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant