meta(debugger/tracing): tracking issue for debugger and tracing improvements

[mds1]

Overview

Placing these in the same issue because a refactor should let us reuse most/all of the same code for both debugging and traces, within both forge and cast. The difference between "trace view" and "debug view" then is just what's shown on the screen. For example, you can imagine the debugger config looking something like this (made up type names within the Options):

struct DebuggerConfig {
  trace: Option<CallTrace>,
  opcodes: Option<Vec<Opcodes>>,
  memory_states: Option<Vec<Memory>>,
  stack_states: Option<Vec<Stack>>,
  srcmap: Option<SrcMap>,
}

where "trace view" simply has None everywhere except for trace, while debugger mode may have everything enabled. Users could toggle each config option on/off in the debugger UI.

The debugger should be interactive to allow for collapsing traces, show/hiding more information, etc. Tenderly debugger/trace UX is very nice IMO so is a good source of inspiration. More info coming soon, need to link existing issues here

Issues

this is a work in progress

• meta(tracing): tracking issue for tracing improvements #3390
• Log hints in verbose output #4743

[zerosnacks]

Closing in favor of #927 + #3390

[mazurroman]

gm Foundry,

I am Roman, founder of Walnut, a web-based transaction debugger and Simulator for Starknet.

I am currently in discussions with the Ethereum Foundation about potentially developing a local debugger for Ethereum with support for debugging Foundry tests (likely as a VSCode extension).

I’m curious: what are your plans regarding this and issues #3390 and #5784? How urgent are those tasks? If we proceed and develop a high-quality EVM debugger, would you be interested in integrating it with Foundry, rather than building your own custom solution? We would greatly appreciate any thoughts you could share on this.

Technically, if we proceed, we will create an open-source, fully local tool, with no dependencies on centralized servers.