Selective compilation of certain Solidity files via foundry.toml

[Vectorized]

Component

Forge

Describe the feature you would like

Suppose I want to include 2 different ReentracyGuard files in Solady.

• ReentrancyGuard.sol (uses regular old sstore).
• ReentrancyGuard.cancun.sol (uses the tstore opcode probably available in solc 0.8.23 in the future).

Compilation will throw an error when using "solc_version" < "0.8.23" or "evm_version" < "cancun".

Suggestion

Suppose Solady's foundry.toml has:

[profile.default]
solc_version = "0.8.21"
evm_version = "paris" # Shanghai will be tested in the CI.
auto_detect_solc = false
optimizer = true
optimizer_runs = 1_000
gas_limit = 100_000_000 # ETH is 30M, but we use a higher value.
remappings = [
  "forge-std=test/utils/forge-std/"
]
selective_compile = [
  { path = "./**/*.cancun.sol", min_solc_version = "0.8.23", min_evm_version = "cancun" }
]

Ideally any library that installs Solady via forge must be able to compile with solc >= 0.8.4 (minimum supported version by Solady).

But if their foundry.toml specifies "solc_version" = "0.0.23" and "evm_version" = "cancun", they will be able to include and compile ReentrancyGuard.cancun.sol.

A project that targets many EVM chains (e.g. for canonical create2 deployments with vanity addresses) would use "solc_version" = "0.0.23" (or any other version that supports paris) and "evm_version" = "paris". They will include the traditional ReentrancyGuard.sol in files.

A project that only targets Ethereum mainnet would use "solc_version" = "0.0.23" and "evm_version" = "cancun". They will include ReentrancyGuard.cancun.sol in files instead.

Why?

I mean... we cannot expect L2s (and Solidity) to be shipping as fast and hardcore as the Foundry team.

PUSH0 was a good test of what's to come.

Additional context

No response

[mattsse]

yeah, we kind of want this in one form or another.

I think this is some form of configuration conditional where a library can allow/disallow certain files based on the configured version

all of this needs to be solved during preprocessing, independently from solc.

I can see how this will become important with new cancun opcodes and already is problematic with push0...

Because this depends on the file itself, I can imagine this could be solved with some natspec custom modifier and via the config like you suggested.

I think it's most important to prevent compilation if evm version is invalid.
but I wonder if the ideal DX would be something like, "if cancun use cancun.sol variant of that file, if < cancun use this file"

but this is likely a niche feature only for certain libraries like solady and should probably be solved via a package manager solution instead.

But adding rules into the config would be possible and we should start with that.

[zerosnacks]

Related: #5715