Check struct compatibility in diamond storage pattern

[frangio]

The diamond storage pattern described in EIP-2535 is gaining popularity. It consists of an internal getter that returns a storage pointer to a struct that is placed in some random location in storage. This is an alternative to storage gaps that is more powerful because it also tolerates different inheritance linearization.

A struct defined in a contract used only in a diamond storage getter should also be checked for layout incompatibilities, but currently isn't

[mudgen]

This is a great idea. Any activity or work on this yet?

[frangio]

The current idea is to add an annotation that can state the intent to use a struct at a specific location.

/// @custom:storage-location L
struct S {
    ...
}

Here L may be a slot number or some other way to identify the location. To give an idea of the latter, it might be eip1967:admin to specify the admin slot defined by EIP-1967, or similarly for some other EIP.

When comparing the layouts of two contracts, these annotations would be taken into consideration causing structs declared to be in the same location to be checked for compatibility.

Additionally, ideally we would check to see that any function that returns a storage pointer to this struct type is indeed using the specified location (details TBD, this is a level of static analysis that we don't have in the plugins yet).

A possible obstacle to this approach is that Solidity currently does not expose docstrings for structs (ethereum/solidity#12295), but this can be worked around using a custom lexer like in solidity-comments (could be precisely that library, it currently extracts normal non-doc comments but adding docstrings as well is trivial).

[mudgen]

Great!