feat(test): include data from fuzz/invariant runs in gas reports

[klkvr]

Motivation

Closes #7313

Now the output of the test --gas-report from the repro is the following:

| test/Inv.t.sol:ContractA contract |                 |       |        |        |         |
|-----------------------------------|-----------------|-------|--------|--------|---------|
| Deployment Cost                   | Deployment Size |       |        |        |         |
| 154332                            | 534             |       |        |        |         |
| Function Name                     | min             | avg   | median | max    | # calls |
| increment                         | 48554           | 48554 | 48554  | 48554  | 1       |
| setNumber                         | 48795           | 68117 | 49077  | 103999 | 256     |


| test/Inv.t.sol:Counter contract |                 |     |        |     |         |
|---------------------------------|-----------------|-----|--------|-----|---------|
| Deployment Cost                 | Deployment Size |     |        |     |         |
| 137113                          | 421             |     |        |     |         |
| Function Name                   | min             | avg | median | max | # calls |
| number                          | 305             | 305 | 305    | 305 | 257     |

Solution

We now collect up to FuzzConfig::gas_report_samples/InvariantConfig::gas_report_samples additional traces of successfull runs of fuzz/invariant tests, then identify and include them into gas report.

Additional samples are not collected when gas report is disabled so there should be no performance overhead for defaut runs.

Not sure if I've chosen the best approach for testing this. Existing --gas-report tests operated on stdout and I needed access to the resulted GasReport object to test count of calls.

[mds1]

With forge snapshot we use a seed to ensure consistent results—sanity checking that --gas-report has the same behavior?

Also it sounds like we always collect gas report samples even if the gas report is not requested, is the idea that the default gas_report_samples is small enough that performance impact is negligible, even for large test suites?

[klkvr]

Also it sounds like we always collect gas report samples even if the gas report is not requested, is the idea that the default gas_report_samples is small enough that performance impact is negligible, even for large test suites?

We are overriding any configured gas_report_samles with 0 if --gas-report flag is not provided which results in underlying testing code not collecting any additional traces

With forge snapshot we use a seed to ensure consistent results—sanity checking that --gas-report has the same behavior?

No, we can consider that, but current output of --gas-report is not consistent as well and depends on the latest fuzz run inputs.

[mds1]

Also it sounds like we always collect gas report samples even if the gas report is not requested, is the idea that the default gas_report_samples is small enough that performance impact is negligible, even for large test suites?

We are overriding any configured gas_report_samles with 0 if --gas-report flag is not provided which results in underlying testing code not collecting any additional traces

Ah thanks, missed this
https://github.com/foundry-rs/foundry/pull/7324/files#diff-289e6e32b190bdcdd1d4512466e34391afa813e748f99ed7316054a0352e7db8R149-R151

With forge snapshot we use a seed to ensure consistent results—sanity checking that --gas-report has the same behavior?

No, we can consider that, but current output of --gas-report is not consistent as well and depends on the latest fuzz run inputs.

Got it, happy to do that in a separate PR to avoid scope creep here

[mattsse]

good to merge @klkvr ?

[klkvr]

yep, sending