Support custom EVM versions

[axic]

Currently the compiler has a setting for "evm version" (introduced in #1117). This setting is basically tied to the Ethereum mainnet hard forks, i.e. homestead, byzantium, istanbul, etc.

Currently each of these options set a bunch of underlying settings (see libsolutil/EVMVersion):

        /// Has the RETURNDATACOPY and RETURNDATASIZE opcodes.
        bool supportsReturndata() const { return *this >= byzantium(); }
        bool hasStaticCall() const { return *this >= byzantium(); }
        bool hasBitwiseShifting() const { return *this >= constantinople(); }
        bool hasCreate2() const { return *this >= constantinople(); }
        bool hasExtCodeHash() const { return *this >= constantinople(); }
        bool hasChainID() const { return *this >= istanbul(); }
        bool hasSelfBalance() const { return *this >= istanbul(); }
        /// Whether we have to retain the costs for the call opcode itself (false),
        /// or whether we can just forward easily all remaining gas (true).
        bool canOverchargeGasForCall() const { return *this >= tangerineWhistle(); }

Additionally it controls the "code size too big" warning enabled since spuriousDragon.

Since custom EVM versions and custom chains come up as a question/discussion once a year, perhaps for the long term we could consider exposing these underlying settings via standard json.

One way I could think is that the evmVersion setting would set the baseline, and modifying any specific setting would override that. The other option is to introduce a new evmVersion called "custom" and require an explicit value for each of the settings listed above.

This of course does not solve the problem of supporting new features, but allows fine tuning for custom chains. It is unclear however if this would be entirely beneficial for them.

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[github-actions]

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.