Component
Forge
Have you ensured that all of these are up to date?
What version of Foundry are you on?
forge Version: 1.1.0-stable Commit SHA: d484a00 Build Timestamp: 2025-04-30T13:50:49.971365000Z (1746021049) Build Profile: maxperf
What version of Foundryup are you on?
foundryup: 1.0.1
What command(s) is the bug in?
forge test
Operating System
macOS (Apple Silicon)
Describe the bug
We discovered that the creation code produced inside forge tests is different than in forge scripts for some of the contracts despite following the standard recommended guidelines to ensure matching bytecodes in such scenarios.
We have narrowed it down to a compiler interpretation of function visibility inside a library that is called from within the main contract.
If a library function is either external or public, the creationCode generated will differ between forge script and forge test. Changing it to internal fixes the issue, probably because the compiler would embed it inside the main contract unlike using delegatecall for external functions. However, this is not a valid workaround as it increases the bytecode size of the main contract defeating its purpose.
This is important because different bytecode will produce different create2 addresses and some of the tests will yield incorrect results while others might not be possible to test at all.
We created a simple example to reproduce the issue using the hello-foundry starter.
Link: https://github.com/chrisciszak/foundry_compiler_issue
Steps to reproduce
- Clone https://github.com/chrisciszak/foundry_compiler_issue
- Run
forge test test/Bytecode.t.sol
- The test fails
- Run
forge script test/Bytecode.t.sol
- The script passes
Any prompt help or workaround would be highly appreciated as we run out of ideas how to ensure compatibility in this scenario.
Component
Forge
Have you ensured that all of these are up to date?
What version of Foundry are you on?
forge Version: 1.1.0-stable Commit SHA: d484a00 Build Timestamp: 2025-04-30T13:50:49.971365000Z (1746021049) Build Profile: maxperf
What version of Foundryup are you on?
foundryup: 1.0.1
What command(s) is the bug in?
forge test
Operating System
macOS (Apple Silicon)
Describe the bug
We discovered that the creation code produced inside forge tests is different than in forge scripts for some of the contracts despite following the standard recommended guidelines to ensure matching bytecodes in such scenarios.
We have narrowed it down to a compiler interpretation of function visibility inside a library that is called from within the main contract.
If a library function is either external or public, the creationCode generated will differ between forge script and forge test. Changing it to internal fixes the issue, probably because the compiler would embed it inside the main contract unlike using delegatecall for external functions. However, this is not a valid workaround as it increases the bytecode size of the main contract defeating its purpose.
This is important because different bytecode will produce different create2 addresses and some of the tests will yield incorrect results while others might not be possible to test at all.
We created a simple example to reproduce the issue using the hello-foundry starter.
Link: https://github.com/chrisciszak/foundry_compiler_issue
Steps to reproduce
forge test test/Bytecode.t.solforge script test/Bytecode.t.solAny prompt help or workaround would be highly appreciated as we run out of ideas how to ensure compatibility in this scenario.