Selective compilation of certain Solidity files via `foundry.toml`

Vectorized commented 10 months ago

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 commented 10 months ago

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 commented 2 months ago

foundry-rs / foundry