foundry-rs / foundry

Foundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.
https://getfoundry.sh
Apache License 2.0
8.02k stars 1.64k forks source link

bug: `traces` field is missing when display option `--json` is set #6922

Open t4sk opened 6 months ago

t4sk commented 6 months ago

Component

Forge

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

What version of Foundry are you on?

forge 0.2.0 (1839c72 2024-01-27T14:45:19.822383666Z)

What command(s) is the bug in?

forge test -vvvv --json

Operating System

Linux

Describe the bug

forge test -vvvv prints the traces but forge test -vvvv --json does not.

Setup

forge init

Commands

forge test -vvvv

Output

[PASS] test_Increment() (gas: 28379)
Traces:
  [28379] CounterTest::test_Increment()
    ├─ [22340] Counter::increment()
    │   └─ ← ()
    ├─ [283] Counter::number() [staticcall]
    │   └─ ← 1
    └─ ← ()

Here is the same command with --json. Traces are missing from the output

forge test -vvvv --json | jq
{
  "test/Counter.t.sol:CounterTest": {
    "duration": {
      "secs": 0,
      "nanos": 13219812
    },
    "test_results": {
      "testFuzz_SetNumber(uint256)": {
        "status": "Success",
        "reason": null,
        "counterexample": null,
        "logs": [],
        "decoded_logs": [],
        "kind": {
          "Fuzz": {
            "first_case": {
              "calldata": "0x5c7f60d70000000000000000000000000000000000000000000000000000000000000cdd",
              "gas": 49625,
              "stipend": 21216
            },
            "runs": 256,
            "mean_gas": 27709,
            "median_gas": 28409
          }
        },
        "labeled_addresses": {},
        "debug": null,
        "breakpoints": {}
      },
      "test_Increment()": {
        "status": "Success",
        "reason": null,
        "counterexample": null,
        "logs": [],
        "decoded_logs": [],
        "kind": {
          "Standard": 28379
        },
        "labeled_addresses": {},
        "debug": null,
        "breakpoints": {}
      }
    },
    "warnings": []
  }
}

Is this a bug? If not how can I get the traces like in the older version?

DaniPopes commented 6 months ago

cc @onbjerg is this a consequence of the tracing refactor?

onbjerg commented 6 months ago

No this is a consequence of the Alloy port, some types are not ser/de

DaniPopes commented 6 months ago

Should be fixed with next revm + evm-inspectors update: https://github.com/paradigmxyz/evm-inspectors/pull/47

zerosnacks commented 1 month ago

Re-running with given setup now yields:

forge test -vvvv
[⠊] Compiling...
[⠢] Compiling 25 files with Solc 0.8.26
[⠰] Solc 0.8.26 finished in 1.16s
Compiler run successful!

Ran 2 tests for test/Counter.t.sol:CounterTest
[PASS] testFuzz_SetNumber(uint256) (runs: 256, μ: 30977, ~: 31288)
Traces:
  [31288] CounterTest::testFuzz_SetNumber(516)
    ├─ [22290] Counter::setNumber(516)
    │   └─ ← [Stop] 
    ├─ [283] Counter::number() [staticcall]
    │   └─ ← [Return] 516
    ├─ [0] VM::assertEq(516, 516) [staticcall]
    │   └─ ← [Return] 
    └─ ← [Stop] 

[PASS] test_Increment() (gas: 31303)
Traces:
  [31303] CounterTest::test_Increment()
    ├─ [22340] Counter::increment()
    │   └─ ← [Stop] 
    ├─ [283] Counter::number() [staticcall]
    │   └─ ← [Return] 1
    ├─ [0] VM::assertEq(1, 1) [staticcall]
    │   └─ ← [Return] 
    └─ ← [Stop] 

Suite result: ok. 2 passed; 0 failed; 0 skipped; finished in 7.51ms (7.06ms CPU time)
{
  "test/Counter.t.sol:CounterTest": {
    "duration": "6ms 584us 664ns",
    "test_results": {
      "testFuzz_SetNumber(uint256)": {
        "status": "Success",
        "reason": null,
        "counterexample": null,
        "logs": [],
        "kind": {
          "Fuzz": {
            "first_case": {
              "calldata": "0x5c7f60d700000000000000000000000000000000000000cc8edadd275ec2b562a63dee4b",
              "gas": 52636,
              "stipend": 21348
            },
            "runs": 256,
            "mean_gas": 31054,
            "median_gas": 31288
          }
        },
        "labeled_addresses": {},
        "duration": {
          "secs": 0,
          "nanos": 6174286
        },
        "breakpoints": {}
      },
      "test_Increment()": {
        "status": "Success",
        "reason": null,
        "counterexample": null,
        "logs": [],
        "kind": {
          "Unit": {
            "gas": 31303
          }
        },
        "labeled_addresses": {},
        "duration": {
          "secs": 0,
          "nanos": 181373
        },
        "breakpoints": {}
      }
    },
    "warnings": []
  }
}

I think this is still an issue