File-level inline assembly blocks

[chriseth]

Just like free functions, inline assembly blocks could be allowed at file level. This would make it possible to write helper functions in yul that can be called from any inline assembly block. Maybe we could even import these yul functions using import statements.

[ekpyron]

Importing should work nicely now that we reserved dots in identifiers!

[chriseth]

Shadowing: if there is a file-level inline-assembly function f, then no contract can be named f.

[axic]

Some relevant issues from the past:

• Cross-Inline-Assembly block functions. #1319 -- pretty much the same
• Adding memory allocation helper to inline assembly #474 -- malloc helper
• "require" helper in assembly #7317 -- require helper

[chriseth]

Exactly, this is a solution to the problem in #1319.

[ekpyron]

To be more precise about importing: Namespaces could be introduced using import statements to get qualified functions like A.f (using import f from file.sol as A). This won't cause conflicts now, since dots are now reserved in inline assembly and have to refer to things in the solidity scope anyways.

To be more precise about the shadowing: yul functions in file-level blocks would occupy the same namespace as solidity objects (be proper Declarations for the compiler) - just referring to them from outside inline assembly would be an error.
[Note: it could even make sense at some point in the future to make such functions callable from solidity in some way, but that'd be quite a separate issue.]

We could reserve one special identifier in Yul, in case we ever decide to expose compiler generated functions in any way (to use it as namespace for those e.g. std and have std.require(...) etc.). This could expose e.g. abi encoding/decoding functions. Again a separate issue though, but maybe also worth keeping in mind for this.

[chriseth]

Discussion: Pretty clear how to do it, only question is whether it is useful.

[cameel]

While working on the yul-phaser I compiled a list of a few publicly available contracts with more substantial assembly blocks to use as input in experiments (#7806 (comment)). It might come in handy if we want to gain more insight into how people organize assembly-heavy contracts in practice:

Source repository	Direct link to .sol file
AztecProtocol/AZTEC	Swap.sol
GNSPS/solidity-bytes-utils	AssertBytes.sol
GNSPS/solidity-bytes-utils	BytesLib.sol
likecoin/likecoin-contracts	LikeChainRelayLogic.sol
Loopring/protocols	LzDecompressor.sol
NutBerry/stack	GatedComputing.sol
NutBerry/stack	LEVM.sol
pvienhage/ghost-wallet	p256.sol
rynobey/multi-exponent	EcOperations.sol
vaporns/solsha1	SHA1.sol
zcoinofficial/solidity-BigNumber	BigNumber.sol

[axic]

Added some examples in #10282: https://github.com/ethereum/solidity/blob/stdlib/stdlib/assembly.sol

[ekpyron]

Not sure why we were wondering if this is useful - at the moment I'd say it rather clearly is and we just had a similar request in #13472, so I'd say we can consider this as "nice-to-have" at least. And I don't see any open design questions or blockers on this.

I'll actually even move it to "must have eventually".