Introduce solidity.evmVersion() to query the target EVM

[axic]

Introduce solidity.evmVersion() function which returns an enum of enum solidity.EvmVersion { Homstead, TangerineWhistle, SpuriousDragon, ... }.

This would mean the solidity identifier is reserved for "language magic", but we could consider such functions to be explicitly importable instead from the special solidity source:

import evmVersion from solidity; // notice that `solidity` is not a literal, but an identifier

This would be useful for implementing features in #10282.

[mudgen]

Is there currently any way to query the EVM to find out what version it is?

[axic]

A more refined statement would be import { evmVersion } from solidity;, but I still think this has to be a special keyword and not a path, because otherwise the expectation would be to have a source available (just like in stdlib).

Potentially this solidity namespace could contain the other native types proposed by @ekpyron, like StackSlot.

[ekpyron]

The proper way of doing this would probably be to expose this as a special yul builtin and then actually expose it to solidity via stdlib? The funny thing here is: is this compile-time constant :-)? It is, if we produce evm bytecode directly... if we first go to Yul, though, we can still generate code for a different evm version from that, that's a bit messy... on the other hand, Yul code is implicitly generated for specific evm versions, it just doesn't make this explicit...

[axic]

Not sure I follow the reasoning for why it should be a Yul builtin, but also see this:

Potentially this solidity namespace could contain the other native types proposed by @ekpyron, like StackSlot.

[ekpyron]

Well, it kind of depends whether we consider Yul code to target a fixed evm version.
In principle, in a lot of cases we could generate Yul as switch lt(evmversion(), 4) case 0 { /* pre constantinople code */ } default { /* post constantinople code */ }, which would still allow pre- and post-constantinople bytecode to be generated from the Yul IR... on the other hand, that also won't work in all cases...

And yeah - actually also only works, if we had a Yul dialect with all builtins, but could still change the evmversion... i.e. you'd need to have shifts as builtins to formulate post-constantinople code.

So yeah, maybe indeed better not to bother with it on the Yul level, nevermind.

[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.

[axic]

This would still be very useful.

[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.