forge: Deploying and testing contracts compiled by older Solidity versions

[Jeiwan]

When compiling a test contract that imports a contract that uses an older Solidity version, it fails with:

Error:
0:
ParserError: Source file requires different compiler version (current compiler is 0.8.10+commit.fc410830.Darwin.appleclang) - note that nightly builds are considered to be strictly less than the released version
--> /Users/jeiwan/.tmp/foundrysolversions/lib/v2-core/contracts/UniswapV2Pair.sol:1:1:
|
1 | pragma solidity =0.5.16;
|

Steps to reproduce:

1. mkdir foundrysolversions && cd $_
2. forge init
3. forge install Uniswap/v2-core
4. Edit src/test/Contract.t.sol and add import "v2-core/UniswapV2Pair.sol";
5. forge test

Is there a workaround? Is it possible to compile contracts with different compilers and then reuse binary code?

[gakonst]

I don't think this is possible in general? You should not be able to import & use a file that is pragma solidity =0.5.16 in a non -0.5.16 file.

[mattsse]

pragma solidity =0.5.16; pins to 0.5.16 and 0.5.16 only, meaning it won't compile with any other version.

this leaves two possible solutions:

• use the exact version yourself (or a range that includes it like >=0.5.16)
• upgrade the contract's pragma to a newer version

There is an unrecommended third possible workaround:
technically, it's not necessarily required to have a version pragma in a solidity file, but it's highly! recommended and the defacto standard. depending on the build tool you don't need a version pragma in your imports.

[gakonst]

Yep, matches my understanding above. Closing then as it's not a Foundry issue and isn't something support-able in any framework afaict.

[Jeiwan]

This is doable in Hardhat, although with a hack. I think it's also possible to deploy binary code compiled by older Solidity compiler as a contract using inline assembly or some other magic. Probably this can be implemented as another cheat code (the VM contract).

This feature can be needed when testint a contract that interacts with third-party contracts deployed on mainnet. For example, a contract that uses flash loans of Uniswap. Upgrading outdated contracts can cause bugs or result in different behavior. Also, since Forge dependencies are git submodule, one would have to fork original repo and add it as a dependency instead of the original one, to be able to save changes.

Mocking is a solution but mocking is generally considered a bad practice because mocks are not exact copies and can differ in behavior. For simple cases like flash loans mocks are ok, but for more complex cases they can be problematic: imagine you used a slightly incorrect mock and then deployed to mainnet where the contract you depend on works differently. At this point though mocks seems like the simplest solution.

[gakonst]

What is the way it's doable in hardhat? Maybe we can streamline that hack?

[Jeiwan]

First step is to compile a dependency contract separately from other contracts. In Hardhat, I use an empty contract like:

pragma solidity =0.5.16;

import "@uniswap/v2-core/contracts/UniswapV2Factory.sol";

contract DependencyUniswapV2 {}

Then, in tests, it can be easily used via:

const Factory = await ethers.getContractFactory("UniswapV2Factory");

getContractFactory is a feature of Hardhat, it loads contracts from artifacts by contract name and it can instantiate a contract from bytecode and ABI:
https://github.com/nomiclabs/hardhat/blob/767f68dee84d6a47cd40153a8ab8552f41a95d5e/packages/hardhat-ethers/src/internal/helpers.ts#L60
I wish we could have something like that in Forge because writing tests in Solidity is so much better than in JS. It also feels like making Solidity compiler import contracts from bytecode is not a big problem, but it might be easier to hack it in Forge first.

[jparklev]

Here's what i'm doing for this atm lmao

[gakonst]

Honestly that's not a bad workaround, maybe something we should add on the stdlib?

2 qs:

1. What does _compileSpace() do?
2. How do you get its interface for further usage in the tests?

[jparklev]

What does _compileSpace() do?

This is in a monorepo, so it's making sure the other pkg has been compiled first (does something like cd ../space-pkg; forge build)

How do you get its interface for further usage in the tests?

Just defining a new interface for it maker-style in this case

maybe something we should add on the stdlib

Yea! Guess it depends if there are any gotchas with appending calldata to bin bytecodes compiled with different versions? I don't know of anything like that, but I would defer to others who are more familiar

[Jeiwan]

I've ended up using the same solution. Learned about it from this blog post:
https://www.libevm.com/2021/12/18/yulp-smart-contract-dev/

[brockelmore]

May i suggest to reduce external dependencies like jq, that we make it a cheatcode for loading deplyoment (and runtime) bytecode from a compiled contract? This would also make the etch cheatcode more useful i imagine

[gakonst]

Supportive @brockelmore

[ncitron]

If nobody else has, I'd like to give this one a shot. I've been wanting this feature for a while now in dapptools/foundry.

[onbjerg]

Is this solved by #440?

[Jeiwan]

@onbjerg Yes! Thanks.