eof: Make use of EOF's SWAPN/DUPN

[ekpyron]

I didn't think through the actual limit cases properly, so we'd need to double-check. Annoying to test SWAP257, though...
I'm marking it as ready for a first review regardless.
Depends on #15845 (merged)

FYI: I'd be happy to remove the swapn{256} and dupn{256} tests here, shrinking the PR by a few thousand lines :-).

[ekpyron]

Note that starting from here this is identical to pop_early_to_avoid_swap17.stack, but, using SWAP17 above, we spent only 2 instead of 3 operations to get here.

[ekpyron]

Actually, that means, I can also just use this as a target directly, which simplifies the tests quite a bit :-).
EDIT: I did that now - but kept the commit with the original larger test for now to make it clear where this is coming from. We can squash it away later.

[ekpyron]

Not sure how valuable this test case really is... but here we have swapn{256}... generating one more variable in the test case, correctly triggers a swap-too-deep.
Also note that we don't run any optimizer here. If we rematerialized here, the code would even become entirely swap-free (and we'd need to prevent reordering by introducing side-effects - luckily without the optimizer this remains rather straight-forward).

[cameel]

IMO better to have it than not. Sometimes unexpected things happen at the limits.

[cameel]

BTW, we could make these at least a little less verbose by adding a test setting for disabling the source locations. I.e. the equivalent of --debug-info none. I'd keep them on by default, but often they don't add much and it would be nice to be able to silence them.

Maybe then we'd also get the functional formatting (i.e. calldatalad(0x0100)) to make it even more compact - not sure when that kicks in, but I suspect it may be the comments preventing it here.

[cameel]

I'm not yet done looking at the tests, but here's what I found so far.

The most relevant things are 3 places that still have hard-coded reachable slots. Two of them look just like heuristics that are now out of sync, but one seems to me like it might result in StackTooDeep in some cases that would be avoided otherwise.

[cameel]

Not necessarily something to fix in this PR, but note that we may not get much coverage for this from some parts of the fuzzer, because it's hard-coded to max 15 variables:

https://github.com/ethereum/solidity/blob/eb216716830f45681df0da7641b4216a255b8946/test/tools/ossfuzz/protoToSol.h#L182-L184

[cameel]

Looks like all the important things are fixed. I'll do one more pass to make sure I did not miss anything and to respond to comments, but I don't expect to find much to change at this point.

I'll also check if I can suggest some tests, but so far I could not come up with any over what you have already. Most changes seem like they indeed should be proven correct by the fact that the existing tests still pass. I'm not entirely sure if we have enough coverage for that, but it's hard to point out any specific cases that might be necessary.

Apart from that, two things we're not really testing are: cases where StackTooDeep does happen (but that would probably require bigger adjustments to test) and gas meter. For the latter the changes in the PR are not complicated, so we should be fine, but we should really have at least some basic coverage for this component. Maybe we should have a custom test case type that lets us import assembly items and shows the calculated cost?

[ekpyron]

Rebased and largely squashed.