Drop support for ancient EVM versions, i.e. for homestead

[ekpyron]

Came up in https://github.com/ethereum/solidity/pull/12205/files#r743092422.

• homestead in particular needs the canOverchargeGasForCall() workarounds, which complicate code (although to be fair it's not that bad)
• the new Yul-EVM code transform currently cannot guarantee not to reorder the gas opcode (although to be fair it could probably be adjusted, s.t. it can, but that would probably mean some more invasive special case handling)

So while that's not an absolutely strong case, maybe it still makes sense to consider dropping support. For that the main consideration is probably:
Are there any live chains that run homestead, resp. any users that may rely on new compiler versions to be able to generate homestead-compatible bytecode?

If not, there's little reason for not dropping the support.

[cameel]

This would be breaking, right?

[ekpyron]

This would be breaking, right?

Probably - although I guess there's no precedent and it might be fair to decide that it's not - I guess we'll only drop support, if we're reasonably sure that doing so in practice doesn't break anything anyways :-).

[axic]

The issue I see is that Solidity is used by many other chains and we want to avoid the need for various forks to emerge. I know that there is such differentiation between the various chains, mostly they may not implement some recent features from Berlin/London, or they implement features non existing on mainnet (however these are mostly in a way, like precompiles, which does not require a change in the compiler)

Now if we start dropping support for older mainnet releases, we may find ourselves in a spot where we drop support for some chains. I do not think this applies to homestead, as I'd imagine most chains are on Byzantium-compatibility (for revert/staticcall/returndata) or even Constantinople-compatibility (for create2).

In the end I think it is important to keep the above in mind.

[chriseth]

I don't think this is such a big problem. Currently the strategy to just have non--optimized code (or code with stack errors) for ancient versions works well enough in my opinion.

[ekpyron]

If we switch to non-optimized code only, then it's really a non-issue.
It would just both be annoying to have to adjust the new code transform to handle this, as well as having to keep the complexity of the stack optimizations in the old code transform because of this...

[ekpyron]

New tendency: even drop everything below constantinople.

[cameel]

Looks like Vyper will be dropping everything older than istanbul in the next release. The PR for that is even already merged: vyperlang/vyper#3470.

[ekpyron]

We did ask around at least a bit already, whether this would be a problem for anyone, but nobody weighed in so far?
We could emit a "deprecated" warning soon to give people a chance to cry out.