Support "calldata" as an overloaded location for reference variables.

[Amxx]

Abstract

Disambiguate "memory" and "calldata" when overloading

Motivation

Lets consider the following library as a minimal example

library L {
    struct S { bytes content; bytes signature; bytes metadata; }
    function getHash(S storage s) internal view returns (bytes32) { return keccak256(s.content); }
    function getHash(S memory s) internal pure returns (bytes32) { return keccak256(s.content); }
    function getHash(S calldata s) internal pure returns (bytes32) { return keccak256(s.content); }
}

We may want to get a hash of the content, or any other value that requires reading par of (but not all of) the structure.
Depending on where the structure lives, copying all of it to memory might be a waste (in our example, signature & metadata might be very large, and are not actually needed in getHash).

In these cases, it is more efficient to pass the structure as a reference, and only load/copy to memory what is actually going to be used.

This is true if the struct is in storage, but a similar logic applies to structures in calldata (even though the saving are smaller).

So far, solidity has no issue handling

    function getHash(S storage s) internal view returns (bytes32) { return keccak256(s.content); }
    function getHash(S memory s) internal pure returns (bytes32) { return keccak256(s.content); }

but adding the third (calldata) version causes an error.

Specification

Distinguish memory and calldata datalocation so that overriden function do not clash when both localities are implemented separatly.

• If a calldata function is available, calldata objects should use it.
• If no calldata function is available, but a memory function is available, then the calldata objets should be copied to memory and the memory function used (as today?)

Backwards Compatibility

TBD

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[Amxx]

this is still relevant

[ekpyron]

Note that even if we did allow the declarations, being able to properly use the overloads would depend on #1256, so this issue depends on #1256