Support storage layout gaps

We often recommend including a storage “gap” in storage layout in order to safely add storage variables when using (multiple) inheritance. We use this pattern ourselves in OpenZeppelin Contracts Upgradeable. However, if a slot in the gap is actually used for a new variable later, the plugins will flag this as an error. We should detect gaps through the conventional __gap name and treat them specially for layout compatibility: allow replacing gap slots with new variables in an upgrade.

[itsermin]

@aquiladev unfortunately there isn’t. I’ll see if I can bump it, as I believe it would be valuable … but I don’t want to make any promise I can’t keep.

This is quite limiting unfortunately for automating upgrades

[frangio]

Sharing my proposed design notes for this feature.

We currently have a levenshtein module that computes a minimum cost edit distance between two storage layouts. A levenshtein edit distance consists of a list of insertion, deletion, and substitution operations that convert one layout into the other. My proposal is to generalize this to a custom edit distance with operations designed for our domain, with something like a “gap shrink” operation. Then, using the levenshtein module (which really stops being about levenshtein and becomes a generalized Wagner-Fischer implementation) we compute the minimum edit distance with the custom operations. That edit distance may include some insertion operations, i.e. storage variables added in the middle of the layout, which we would normally disallow, but we can now allow them if they are followed by a matching gap shrink operation of the right size.

Furthermore, we should tune the costs of operations to make sure that the minimum cost edit distance is the one that would include the operations we’re looking for. This should be simply a matter of giving lower cost to operations that we want to prioritize, e.g. the gap shrink should be a low cost operation.