Test runner panics on high verbosity and in debug mode

[jmcph4]

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 (ceb739a 2024-02-01T00:22:50.008089969Z)

What command(s) is the bug in?

forge test

Operating System

Linux

Describe the bug

Actual Behaviour

$ forge test -vvvvv --debug check_createWithdrawRequest_sanity
The application panicked (crashed).
Message:  called `Option::unwrap()` on a `None` value
Location: crates/forge/bin/cmd/test/mod.rs:283

This is a bug. Consider reporting it at https://github.com/foundry-rs/foundry

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 7 frames hidden ⋮                               
   8: core::panicking::panic::h195fc2a96298d4c3
      at <unknown source file>:<unknown line>
   9: forge::cmd::test::TestArgs::execute_tests::{{closure}}::h7e0dafa9ef6a36be
      at <unknown source file>:<unknown line>
  10: forge::cmd::test::TestArgs::run::{{closure}}::hf1b1f24d4c3f2c48
      at <unknown source file>:<unknown line>
  11: foundry_cli::utils::block_on::hb1f470968c0c4d54
      at <unknown source file>:<unknown line>
  12: forge::main::h382e48e306f7bde7
      at <unknown source file>:<unknown line>
  13: std::sys_common::backtrace::__rust_begin_short_backtrace::h37c55d94243bd5c4
      at <unknown source file>:<unknown line>
  14: std::rt::lang_start::h138f58e8ad1c056f
      at <unknown source file>:<unknown line>
  15: __libc_start_main<unknown>
      at <unknown source file>:<unknown line>
  16: _start<unknown>
      at <unknown source file>:<unknown line>

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.
Aborted (core dumped)

The test iterator never yields, so the resulting Option from next() is None:

https://github.com/foundry-rs/foundry/blob/ceb739ac9e79f91b23ba3a3dfe1348569b1e16f2/crates/forge/bin/cmd/test/mod.rs#L283

Expected Behaviour

I expect:

• the test runner not to panic
• the test runner to drop me into the debugger at the start of execution of the first failing test case (due to the fuzzing nature of the test in question)

Remarks

I sense this is somehow related to the naming of the test case in question: it does not start with the usual test prefix and the testing contract in question contains no other tests -- this would explain why the test iterator is empty and is perhaps a too-rigid assumption on the part of the subsequent unwrap call.