Component

Forge

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

• [X] Foundry
• [ ] Foundryup

What version of Foundry are you on?

nightly-2e99f7fdaef6a7aaeb426b02ef87e052cc14f68b

What command(s) is the bug in?

No response

Operating System

Linux

Describe the bug

We use the foundry-toolchain github action in our CI and it started failing in the last few hours with failures like this:

forge: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by forge)
forge: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by forge)
forge: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by forge)

Is there a problem with the nightly release?

I didn't include the proper forge --version string, because forge can't even run that in our CI. It started failing after the latest release:

• latest release broken: https://github.com/foundry-rs/foundry/releases/tag/nightly-2e99f7fdaef6a7aaeb426b02ef87e052cc14f68b
• previous one is fine: https://github.com/foundry-rs/foundry/tree/nightly-f6361e6ddb6af62bbf6e122d0d8b27d2f5f6b42d

Instead of collecting here and here, it’d be nice if we could have an iterator which we can stream over

That'd allow us to then iterate in parallel here for nicer UX & speed

Add the ability for forge to use a solidity file to create a contract on mainnet and arbitrary deploy scripts by adding a cheatcode. You could do something like:

contract t {
    function deployMyContract() {
        uint256 input1 = dep.someFunc();
        vm.mainnetDeploy();
        MyContract t = new MyContract(input1);
    }
}

Component

Forge

Describe the feature you would like

A common use case is configuring test params with environment variables, with the RPC URL used for forking tests being a popular example. Right now there is now way to specify in the config file to use a certain environment variable for fork URLs, and instead you'd have to pass this in to the test command, e.g. forge test --fork-url $MY_RPC_URL

Additional context

No response

Component

Forge

Describe the feature you would like

The formatter uses a configuration with hardcoded values. The goal is to define the input format for the configuration (i.e. whether the configuration will be defined in a separate file like fmt.toml or it will become a part of foundry config) and, potentially, expand the options.

Currently, the supported configuration values are:

• line_length - maximum line length where formatter will try to wrap the line
• tab_width - number of spaces per indentation level
• bracket_spacing - print spaces between brackets

Additional context

No response

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 (70f4fb5 2022-11-02T00:05:06.592613Z)

What command(s) is the bug in?

forge test

Operating System

Linux

Describe the bug

Hello, after updating forge-std dependency foundry started crashing with arithmetic operation overflow error. The issue is occuring locally on my M1 Macbook as well as in a linux docker container in CI. Here is the code and here is the log of a failing CI pipeline.

Update

The bug is not related to forge-std (the forge-std update simply made it occur more frequently). The bug is caused by overflow in smart contract execution.

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 (b951f65 2022-03-26T04:46:06.407207863+00:00)

What command(s) is the bug in?

forge build

Operating System

Linux

Describe the bug

When I open a new project but change the solidity version to 0.6.12 forge build fails:

$ forge init forge-2
Initializing $PATH/forge-2...
Installing ds-test in "$PATH/forge-2/lib/ds-test", (url: https://github.com/dapphub/ds-test, tag: None)
    Installed ds-test
    Initialized forge project.
$ cd forge-2
$ forge build
[⠊] Compiling...
[⠢] Compiling 3 files with 0.8.10
Compiler run successful
$ sed -i 's/0.8.10/0.6.12/' src/Contract.sol 
$ grep pragma src/Contract.sol
pragma solidity 0.6.12;
$ forge build
[⠢] Compiling...
Error: 
   0: Solc Error: 

Location:
   cli/src/cmd/utils.rs:40

Backtrace omitted.
Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
$ forge --version
forge 0.2.0 (b951f65 2022-03-26T04:46:06.407207863+00:00)

Component

Anvil

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 (dc83894 2022-06-11T00:06:34.928765727Z)

What command(s) is the bug in?

anvil

Operating System

Linux

Describe the bug

I'm trying to test submitting transactions through Metamask connected to anvil (localhost:8545).

This is the example anvil command I'm running:

anvil --fork-url="https://eth-mainnet.alchemyapi.io/v2/XXXXXXXXXXXXXXXXXXXXXXXXX" --fork-block-number=14812197 --port=8545 -b=5 --chain-id=1

Example steps I've done to reproduce:

1. I fork a specific block, set the block time to be a certain interval
2. Launch opensea.io and sign in with one of my wallets that has an NFT
3. List the item and in the process, calling setApprovalForAll on the NFT
4. Notice that the transaction never goes through and anvil just freezes up (No blocks are getting produced anymore every 5s, it just seems to completely freeze and hang)

Alright, opening for review since it's growing too much. Let's iterate from here.

Summary:

1. Functions should start with invariant. eg: invariant_neverFalse()
2. Invariants have the following parameters on the config file

    /// The number of runs that must execute for each invariant test group.
    pub invariant_runs: u32,
    /// The number of calls executed to attempt to break invariants in one run.
    pub invariant_depth: u32,
    /// Fails the invariant fuzzing if a reversion occurs
    pub invariant_fail_on_revert: bool,
    /// Allows randomly overriding an external call when running invariant tests
    pub invariant_call_override: bool,

2. An invariant with depth of 15 and 256 invariant_runs will have a total of 3840 calls (excluding the invariant checks), if everything succeeds.
3. We currently fuzz the sender_address, target_address and calldata. 3.1 This data is generated by different proptest::TestRunner. 3.2 The data is influenced by a dictionary that is filled with new values throughout the runs.
4. Invariants are checked right after setUp() and before anything is called.
5. After each call we: 4.1 Collect stack/memory data to add to the fuzzing dictionary. 4.2 Collect newly created contracts and add them as potential target_address. 4.3 Make calls to the test contract invariant* functions. If any fails, we exit the run. 4.4 If all invariants have been broken, then exit asap.

Filtering

To better bound the test space there are certain filters that can be used:

• targetContracts(): address[]: a contract address will be chosen from this list.
• targetSenders(): address[]: 80% chance that a contract address will be chosen from this list.
• targetSelectors(): (address, bytes4[])[]: adds to targetContracts list, and only the selectors provided will be called.
• excludeContracts(): address[]: contract addresses from the setup process which are to be excluded from being targeted.

Unsafe/External call overriding

invariant_call_override allows for an external call to be overridden to simulate unsafe calls. This feature is false by default, since it requires some work, although it's already functional. (eg. testdata/fuzz/invariant/InvariantReentrancy.t.sol). More: https://github.com/foundry-rs/foundry/pull/1572#issuecomment-1186479575

Examples

testdata/fuzz/invariant/
├── InvariantInnerContract.t.sol
├── InvariantReentrancy.t.sol
├── InvariantTest1.t.sol
└── target
    ├── ExcludeContracts.t.sol
    ├── TargetContracts.t.sol
    ├── TargetSelectors.t.sol
    └── TargetSenders.t.sol

1 directory, 7 files

Follow-up (in no particular order)

• [ ] Improve report (https://github.com/foundry-rs/foundry/pull/1572#issuecomment-1191969303, https://github.com/foundry-rs/foundry/pull/1572#issuecomment-1193141900)
• [ ] Export failures in a friendly format.
• [ ] Replay (https://github.com/foundry-rs/foundry/issues/991#issuecomment-1107533935)
• [x] Filter by artifact name. (giving priority here)
• [ ] Proxy Support
• [ ] Improve Call override report (current trace/report is a bit misleading)
• [ ] Time based (just set up a real big invariant_runs for now...)
  • [ ] Parallelize runs if time is infinity
• [x] Shrinking
• [ ] Save >1 cases per broken invariant.
• [ ] User defined weights (https://github.com/foundry-rs/foundry/pull/1572#discussion_r934075997)
• [ ] Rename fuzz_seed to rng_seed

ref #849

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 (a84a281 2022-04-16T00:15:54.385011+00:00)

What command(s) is the bug in?

forge create

Operating System

macOS (M1)

Describe the bug

Still getting a Dynamic linking not supported in create command error after changing foundry.toml when deploying to a testnet.

First ran forge create Library which works fine.

Got the address from that then add the following line to foundry.toml

libraries= ['./src/lib/LibraryContract.sol:Library:0xaddress']

I've also tried adding the contract that imports the library:

libraries= ['./src/Contract.sol:Library:0xaddress']

Component

Forge

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

• [ ] Foundry
• [X] Foundryup

What version of Foundry are you on?

forge 0.2.0 (6130af7 2022-04-06T00:04:11.858449+00:00)

What command(s) is the bug in?

forge verify-contract

Operating System

macOS (M1)

Describe the bug

Trying to verify an optimism contract with:

forge verify-contract --chain-id 69 --num-of-optimizations 1000000 --constructor-args < abi-encoded-args > --compiler-version v0.8.13+commit.abaa5c0e < contract-address > < path:contract > < etherscan-key >

does not work. When verifying the verification I get the message below which is not very telling. Not sure what could be wrong, followed the docs very closely.

Error: 0: Contract verification failed: Response: NOTOK Details: Fail - Unable to verify

Component

Other (please describe)

Describe the feature you would like

Upgrade XCode SDK and use latest linker for perf.

compile take long. foundry too many thingys. make go faster. use latest lld linker, much improve

Background

Currently foundry is building against XCode 12.3 SDK (released on 26 Jan 2021) for providing macOS binaries for both x86 and aarch64. This is the last version of XCode that provides support for macOS 10.15.4+.

With Xcode 14.2 released a few weeks ago aarch64 (m1/m2) users can enjoy stupid fast builds thanks to the massive upgrades Apple has done to the long neglected ld64.lld linker

See Apples wwdc2022 presentation on the changes made for the linker and an additional presentation specific to runtime info on ld64 linker updates with XCode 14

Proposed Solution

Add an ADDITIONAL build for aarch64 users or provide a link for those users to grab it I am building them for my own usage as the benefit is worth it.

• additional binary using an upgrade XCode 14 SDK and l64.lld linker
• consider deprecating support for anything below macOS 11
• construct benchmarks for both CI build time and user usage

For XCode >14 use ld64.lld with fixes

Building with ld64.lld

gh repo clone foundry-rs/foundry && cd foundry
wget https://github.com/keith/ld64.lld/releases/download/12-22-22/ld64.tar.gz 
tar -xf ld64.tar.gz 
RUSTFLAGS="-Clink-arg=-fuse-ld=$PWD/ld64.lld" cargo build --release --bins --target aarch64-apple-darwin

Speed Improvements

We can see the build time for the entire repo is 13m 21s

Build times using default configuration was just under 12m 58s on my local machine

Build times using the additional linker and XCode 14 resulted in a build time of 4m 51s.

usr@foundry:~$  Finished release [optimized] target(s) in 4m 51s

References

• https://discourse.llvm.org/t/marketing-and-release-of-mach-o-lld/63143
• https://lld.llvm.org/MachO/index.html
• https://lld.llvm.org/MachO/ld64-vs-lld.html
• https://github.com/bluewhalesystems/sold NOTE This is a commercial linker that claims to have the fastest linker, https://bluewhale.systems/

Additional context

I can literally recompile foundry 3 times over while u still be compiling, we are not the same (arch)

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 (848bb44 2022-12-28T00:13:43.163127Z)

What command(s) is the bug in?

forge build

Operating System

Linux

Describe the bug

On OSX, forge does not seem to care too much about the capitalization of import file names. For example this:

import "forge-std/test.sol";

Works perfectly fine on a Mac even tho it should be Test.sol, while in CI it will yield this message:

Run forge build --sizes
Error: 
Failed to resolve file: "/home/runner/work/athena/athena/lib/forge-std/src/test.sol": No such file or directory (os error 2).
    --> "/home/runner/work/athena/athena/test/Athena.t.sol"
        "forge-std/test.sol"
    Check configured remappings.

This error message had me pretty confused for a while (it's only off by 2 characters), esp since it worked on Mac.

The error message isn't necessarily at fault, but this whole flow was a little confusing to debug for multiple reasons. I'd argue it's a small footgun that it wouldn't hurt to mitigate somehow, maybe by:

• Ensuring foundry is case insensitive on linux or
• Ensuring foundry is case sensitive on OSX

and/or

• Augmenting this error message to note if there's a similar file with different caps

Component

Forge

Describe the feature you would like

As title, would be useful to have a mode to rerun all the failing tests.

Additional context

No response

Component

Forge

Describe the feature you would like

As title, it would be useful in Forge to be able to get a debug_traceTransaction style trace for a test case, in case you want to look at the exact storage ops or something.

Additional context

No response

Component

Forge

Describe the feature you would like

If you have a failing test case, and there are many errors, the first error is probably more indicative of where to start debugging rather than the last. Currently it reports the last, which can be a bit misleading.

Additional context

No response