Skip to content

Conversation

@r0qs
Copy link
Member

@r0qs r0qs commented Dec 20, 2025

This is a follow-up PR suggested in #15984 (comment)

After the changes in #15984, the evmasm pipeline now supports copying nested calldata dynamic arrays to storage by utilizing existing Yul utility functions. Previously, the old assembly implementation could not handle such cases. In #15984, we intentionally maintained this limitation temporarily for backward compatibility.

@r0qs r0qs self-assigned this Dec 20, 2025
@r0qs r0qs force-pushed the evmasm-nested-calldata-array-to-storage branch from edb0453 to ab3a028 Compare December 20, 2025 20:42
}
}
// ====
// compileViaYul: true
Copy link
Member Author

@r0qs r0qs Dec 20, 2025

Choose a reason for hiding this comment

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

Note that, this test was restricted to via-IR only, but it would never actually be captured by the removed assertion. The test copies S[][] from memory to storage, but since the base type is an array, it enters the nested array check (i.e. if block) instead of the else block. And since it copies from memory (not calldata), the calldata-only assertion passes.

Copy link
Member Author

@r0qs r0qs Dec 20, 2025

Choose a reason for hiding this comment

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

Although #15984 refactored this part of the code, the behavior appears to predate those changes. The original code already had the same if-else structure that routes S[][] to the nested array check instead of the struct check for this specific case. See the original code here: https://github.com/argotorg/solidity/pull/15984/changes#diff-870828b8ab9a87c930141e3bde431c7976e1ef6c848cd2473a9cf018ab1e5ec8L184

@r0qs r0qs changed the title Enable nested calldata dynamic arrays to storage copy in evmasm pipeline Enable copying of nested calldata dynamic arrays to storage in evmasm pipeline Dec 20, 2025
@r0qs r0qs marked this pull request as ready for review December 20, 2025 21:19
@github-actions github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label Jan 4, 2026
@argotorg argotorg deleted a comment from github-actions bot Jan 5, 2026
@r0qs r0qs removed the stale The issue/PR was marked as stale because it has been open for too long. label Jan 5, 2026
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.

2 participants