Compilation Caching Not Working As Expected When Moving Between Commits (forge verify-bytecode)

[blmalone]

Component

Forge

Have you ensured that all of these are up to date?

• [X] Foundry
• [X] Foundryup

What version of Foundry are you on?

forge 0.2.0 (c486fca 2024-05-06T00:20:07.911403000Z)

What command(s) is the bug in?

forge verify-bytecode 0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1 SystemConfig --rpc-url $MAINNET_RPC_URL --etherscan-api-key $ETHERSCAN_API_KEY

Operating System

macOS (Apple Silicon)

Describe the bug

Steps to reproduce

I've noticed two cases of unexpected behavior.

1. Redundant compilation on Optimism repo tag: op-contracts/v1.1.0

# Clone optimism monorepo
git clone https://github.com/ethereum-optimism/optimism.git 

cd optimism

# Clean env and install dependencies then navigate to foundry project and install deps
git checkout op-contracts/v1.1.0 &&
        pnpm clean && pnpm install && pnpm build &&
        cd packages/contracts-bedrock &&
        rm -rf lib/ && forge clean && forge install

# Run forge verify-bytecode (watch as it compiles the code, this is expected)
# You'll have to add in your own API keys for this command.
forge verify-bytecode 0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1 SystemConfig --rpc-url $MAINNET_RPC_URL --etherscan-api-key $ETHERSCAN_API_KEY

# e.g. 
# Compiler output:
# [⠒] Compiling...
# [⠢] Compiling 82 files with Solc 0.8.25
# [⠆] Compiling 286 files with Solc 0.8.15
# [⠰] Compiling 1 files with Solc 0.5.17
# [⠒] Compiling 34 files with Solc 0.8.19
# [⠑] Solc 0.5.17 finished in 82.85ms
# [⠆] Solc 0.8.19 finished in 2.16s
# [⠒] Solc 0.8.25 finished in 2.63s
# [⠢] Solc 0.8.15 finished in 74.53s
# Compiler run successful!
# Creation code did not match - this may be due to varying compiler settings
# EVM version mismatch: local=paris, onchain=london
# Runtime code matched with status partial

# Run the same command again
forge verify-bytecode 0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1 SystemConfig --rpc-url $MAINNET_RPC_URL --etherscan-api-key $ETHERSCAN_API_KEY

# You'll notice it doesn't use the cache, instead it recompiles again. Producing the same output as above.

2. Wrong cache is used across tags: op-contracts/v1.3.0 and op-contracts/v1.1.0

# Clear any git changes in the optimism repo
git restore .

# Clean env and install dependencies then navigate to foundry project and install deps
git checkout op-contracts/v1.3.0 &&
        pnpm clean && pnpm install && pnpm build &&
        cd packages/contracts-bedrock &&
        rm -rf lib/ && forge clean && forge install

# Run forge verify-bytecode (watch as it compiles the code, this is expected)
# You'll have to add in your own API keys for this command.
forge verify-bytecode 0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1 SystemConfig --rpc-url $MAINNET_RPC_URL --etherscan-api-key $ETHERSCAN_API_KEY
# Notice it fully compiles as expected

# Navigate back to optimism/ and then clear any local git changes
cd ../../ && git restore .

git checkout op-contracts/v1.1.0

cd packages/contracts-bedrock

# Run the same command
forge verify-bytecode 0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1 SystemConfig --rpc-url $MAINNET_RPC_URL --etherscan-api-key $ETHERSCAN_API_KEY

# Notice no compilation output. It reuses compilation output from op-contracts/v1.3.0

[yash-atreya]

This is due to https://github.com/foundry-rs/foundry/pull/7358.

On v1.1.0 build_info = true in foundry.toml, which disables caching and forces compilation. Whereas, on v1.3.0 the build_info flag is removed from foundry.toml, thus enabling the cache.

[mds1]

I think the solution here is what we discussed with @klkvr in the past—instead of disabling cache, the build info flag should generate a new build-info on each compiler run, and we link artifacts to their corresponding build info, like hardhat does.

[blmalone]

@yash-atreya do you expect this issue to be worked on anytime soon?

[klkvr]

we've improved build-info tracking and enabled cache for runs with --build-info flag, so this should be resolved I believe https://github.com/foundry-rs/foundry/pull/8164

[zerosnacks]

Following up on this, @blmalone could you check if you are still running into issues? If not we can mark this as resolved

[blmalone]

@zerosnacks I tried to test this to confirm it's working but it seems another bug has been introduced: https://github.com/foundry-rs/foundry/issues/8555

[zerosnacks]

For reference, related PR for #8555 : https://github.com/foundry-rs/foundry/pull/8560

[blmalone]

Going to mark this as resolved as I'm not seeing the same behavior anymore.