feat: show latest `evmVersion` supported by each chain in each section and overall

[frangio]

The opcodes section lists opcodes separately and mentions evmVersion where appropriate, but it would also be nice to summarize this at the top and simply say the latest evmVersion that each chain supports.

Concept:

[mds1]

I like this idea, my only hesitation is around the fact that the mainnet hard forks don't map cleanly to L2s so I want to be careful about giving the wrong impression.

For example, Shanghai added support for PUSH0 (EIP-3855) but also limited initcode size (EIP-3860). In the future if L2s support PUSH0, but don't limit initcode, they do support shanghai from the opcode/compiler-settings perspective, but they do not support shanghai from other perspectives like initcode size limits. (Offhand I'm unsure if solc will warn about initcode size being exceed in all cases, or only if the selected evm version is shanghai)

Though I agree it's really useful to know the max safe evmVersion to use when compiling for a given chain, so I'll think on this one more. For a given chain, each section might have a different "latest supported evm verion", and perhaps just highlighting/explaining that with some text is sufficient

[frangio]

Yeah that's a good point. Looking at the Solidity docs it sounds like evmVersion controls mainly opcode availability and opcode costs, which may affect optimizations. I don't see a mention of code size limits.

Perhaps instead of "latest evmVersion supported" the concept should be "suggested evmVersion" to avoid implying too much.

[mds1]

Ah "suggested evmVersion" is a nice compromise. Perhaps we have that at the top of each section, with an overall suggested version at the top which is simply the oldest of each section's versions

[mds1]

Proposed final spec for this feature:

• Each section gets a new latestEvmVersion: MainnetHardfork variable, where MainnetHardfork is the enum of all mainnet hardforks
• This variable indicates the latest mainnet fork that section is compatible with. For example, a chain without PUSH0 would have Paris in the opcodes section, a chain with PUSH0 would have Shanghai
• Some sections may be directly applicable here, for example info on available node implementations. For these we can simply say Not applicable to make it clear the data is not missing
• The top of the diff would have an "overall latest evm version" displayed for each chain, which is the oldest EVM version seen across all sections.
• The ordering of hardfork names is not intuitive, so we should also expose that in the UI so users can more clearly infer which chain supports newer features