ICE: invalid utility Yul generated for calldata→storage copy of struct containing `function() external` member (related to #12057)

[msooseth]

Description

Pushing a calldata struct into a storage array — where the struct has a function() external member — produces invalid utility Yul that fails the inline-assembly parse and surfaces as an Internal Compiler Error. The Yul errors are the same shape as #12057 (2-slot stack vs 1-slot storage mismatch for external function pointers feeding a 1-value RHS into a 2-variable declaration), but the codegen path is different: this is a calldata→storage struct copy via .push(), and it triggers on both legacy and --via-ir, so the fix that closed #12057 doesn't cover this shape.

Minimal reproducer

Gist: https://gist.github.com/msooseth/108f50796d4c3656b4e0770f35348e73

contract c {
    struct S { uint16 a; uint16 b; function() external payable d; }
    S[] data;
    function test(S calldata c) public { data.push(c); }
}

$ solc --bin repro.sol            # legacy
$ solc --via-ir --bin repro.sol   # via-IR

Both fail. The relevant errors in the generated Yul are identical in both pipelines:

Error (3812): Variable count mismatch for declaration of "memberValue_0, memberValue_1": 2 variables and 1 values.
Error (7000): Function "read_from_calldatat_function_external_payable$__$returns$__$" expects 1 arguments but got 2.

• Legacy throws at libsolidity/codegen/CompilerContext.cpp:464 (appendInlineAssembly).
• via-IR throws at libsolidity/interface/CompilerStack.cpp:866 (loadGeneratedIR).

Diagnostic size can explode

Gist: https://gist.github.com/msooseth/75e4cb4ca4b9d68286aab897c52840f3

The error message embeds the full encoded type in generated Yul function names, and the entire generated prelude is dumped verbatim in the ICE output. With a pathologically deep array type elsewhere in the same struct, a 13-line contract produces a multi-hundred-megabyte error message:

contract c {
    struct S {
        uint16 a;
        uint16 b;
        uint[][][][][][][][][]…[][]  // ~370 nesting levels
                       […][3] c;
        function() external payable d;
    }
    S[] data;
    function test(S calldata c) public returns (uint16) { data.push(c); }
}

Output of solc --bin on this: ~101 MB / ~84,800 lines (vs ~18 KB on the minimal reproducer above — same bug, ~5,600× more text). Each [] level extends the encoded type into the names of utility functions like update_storage_value_offset_0_t_array$_..._dyn_storage(...), and those names are repeated throughout the dumped prelude.

Environment

• Compiler version: 0.8.36-develop.2026.5.18+commit.090bc8ff (top of develop)
• Related: [Sol->Yul] Invalid IR generated during copy of dynamically sized storage arrays of function type #12057 (same root cause class; closed but its fix does not cover this shape)

[msooseth]

The almighty LLM says:

Root cause — argotorg/solidity #16751

Source: libsolidity/codegen/YulUtilFunctions.cpp, copyStructToStorageFunction (line 3762).

Bug: the <?fromCalldata> branch of the per-member Whiskers template (lines 3800–3811):

<?fromCalldata>
    let <memberValues> :=
        <?dynamicallyEncodedMember>
            <accessCalldataTail>(value, memberSrcPtr)
        <!dynamicallyEncodedMember>
            memberSrcPtr                              // 1 value into N LHS
        </dynamicallyEncodedMember>

    <?isValueType>
        <memberValues> := <read>(<memberValues>)     // N args into a 1-arg readFromCalldata
    </isValueType>
</fromCalldata>

For function() external payable, stackItems().size() == 2, so <memberValues> = memberValue_0, memberValue_1:

• let memberValue_0, memberValue_1 := memberSrcPtr → error 3812.
• ... := read_from_calldata_...(memberValue_0, memberValue_1) → error 7000 (readFromCalldata takes 1 arg).

The <?fromMemory> branch right below already does it correctly in one line: let <memberValues> := <read>(memberSrcPtr). The fix is to collapse the calldata value-type case to the same shape.