deployCode/getCode no longer works with different profiles

[amusingaxl]

Component

Forge

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

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (14daacf 2024-04-09T00:16:23.595685880Z)

What command(s) is the bug in?

forge test

Operating System

Linux

Describe the bug

This issue is related to #7569

I have a project that requires multiple solidity versions configured as the following:

[profile.default]
src = 'src'
out = 'out'
script = 'script'
libs = ['lib']
solc_version = '0.8.16'
optimizer = true

[profile.0_6_x]
# `src` must be different fot it to work.
# We also recommend putting all Solidity test files and scripts inside `src*/`.
src = 'src-0_6_x'
out = 'out'
script = 'script-0_6_x'
# The order matters! When using `forge install` with FOUNDRY_PROFILE=0_6_x,
# it will use the first directory as the installation path.
# If the library is compatible with all versions,
# you can install it with the default profile.
libs = ['lib-0_6_x', 'lib']
solc_version = '0.6.12'
optimizer = false

Some of the tests are required to deploy contracts from 0_6_x, so I leverage the deployCode cheatcode to do it. The only gotcha was that I needed to run 2 commands when testing:

FOUNDRY_PROFILE=0_6_x forge build
# builds and runs tests with the default profile
forge test

This used to work until recently, but now I'm facing an error like this one:

Encountered 1 failing test in src/VestedRewardsDistribution.t.sol:VestedRewardsDistributionTest
[FAIL. Reason: setup failed: No matching artifact found] setUp() (gas: 0)

The specific line of code that causes that issue is:

deployCode("DssVest.sol:DssVestMintable", abi.encode(address(result.rewardsToken)))

DssVestMintable is defined in lib-0_6_x/dss-vest/DssVest.sol. To force the compiler to find it, there's a src-0_6_x/Imports.sol file that imports it.

I checked and the file out/DssVest.sol/DssVestMintable.json still exists in the directory, and it's not wiped out when I run forge build with no profile or forge test.

I'm not sure why this change in behavior was done in the first place, but I would kindly ask if we could have this capability back, otherwise it would be very painful to deal with cross-version compilation with Foundry.

[Evalir]

cc @klkvr this also seems related to other recent deployCode issues

[klkvr]

yeah, this is caused by the added validation of getCode cheatcode input. we've considered such usecase and added a configuration flag to disable the checks. try adding unchecked_cheatcode_artifacts = true to your foundry.toml

ref #7334 (comment)

[klkvr]

@amusingaxl though curious why are you using different profiles for different versions? did you have any issues with foundry multi-version compilation?

[amusingaxl]

@amusingaxl though curious why are you using different profiles for different versions? did you have any issues with foundry multi-version compilation?

Maybe I missed when this feature was added. I've been using profiles for that for a long time and didn't mind to check back.

Although in this specific case, I do need different profiles because 0.6.x contracts must have optimizations disabled, while 0.8.x ones can have them enabled.

[amusingaxl]

Regarding that "multi-version compilation", where exactly is this documented? I can't seem to find it.

[klkvr]

It is enabled by default if you don't have a solc version specified in the config https://book.getfoundry.sh/reference/config/solidity-compiler#auto_detect_solc

[amusingaxl]

That doesn't work quite well with most workflows I know.
The standard practice is to leave a floating pragma on source files and fix the version in foundry.toml.
This avoids code hidden inside dependencies being compiled with a version that has a bug.
In fact, I only use profiles if I need to support different solidity "major" versions, but then I have exactly 2 compiler versions being applied at once, not many of them.