Fix ICE when assigning calldata Struct with external function type member to storage variable.

[matheusaaguiar]

fix #16717.

[github-actions]

This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale label is removed.

[nikola-matic]

Gonna have to move this up into 0.8.37.

[nikola-matic]

I would add a few more tests:

1. struct with external function ptr + uint64 (packing)
2. struct with external function ptr + uint256[] array (dynamic)
3. array of structs with external function ptr, i.e.

contract C {
  S[] storageStruct;
  ....
}

[nikola-matic]

I've got another test with malformed function pointers:

struct S {
    function(uint) external fn_uint;
}

contract C {
    S storageStruct;

    function test(S calldata calldataStruct) public returns (bool) {
        storageStruct = calldataStruct;
        return true;
    }
}
// ----
// test((function)): "01234567890123456789abcd" -> true
// test((function)): 0x3031323334353637383930313233343536373839616263640000000000000001 -> FAILURE
// test((function)): 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff -> FAILURE

You can call this one copy_from_calldata_to_storage_external_function_type_member_invalid.sol.

Tests that 8 bytes of padding following the 24 byte address is zero, otherwise should revert (which it does, I ran it locally :)

Push this and I'll approve and merge.

[matheusaaguiar]

@nikola-matic added your suggested test.

[cameel]

This introduces a silent assumption that value types are never dynamically encoded. I think that's true now, but such types are technically possible in the encoding - it would be a case where you have an offset in the head and the value is fixed-size, but still stored in the tail.

No need to handle that, but please at least explicitly assert that dynamicallyEncodedMember && isValueType is impossible.

[matheusaaguiar]

Right.
Though before, in that case, it would default to the one read method for value types, possibly generating a miscompilation, I guess.
Added an assertion in the form: p -> q (= !p v q), with p: dynamically encoded, q: not value type.