feat(debugger): Debug Adapter Protocol

[llllvvuu]

Component

Forge

Describe the feature you would like

Support Microsoft's Debug Adapter Protocol (DAP), so that folks can use the debuggers built into VSCode / Neovim / Emacs / Helix / etc.

They handle all of the same UI stuff (e.g. Disassembly View, memory hex view) and more, without having to leave your IDE (can launch tests from the gutter, set breakpoints interactively in the code editor, etc). Actually every feature of the current debugger can be expressed in DAP, e.g. type SteppingGranularity = 'statement' | 'line' | 'instruction';. Here's another one: https://github.com/robertaachenw/solidity-debugger/blob/main/VSCodeExt/src/mockDebug.ts

Additional context

I mentioned this in a comment somewhere, but it could be good to track it as its own issue.

I could take a look when the debugger is in a more stable state. It probably involves exposing library bindings so that a headless executable could be built (but who knows, maybe communicating with a subprocess via stdin could be viable). Ideally it could serve over TCP (vscode.DebugAdapterServer) or stdio (vscode.DebugAdapterExecutable).

Here's an explanation of how it works: https://microsoft.github.io/debug-adapter-protocol//overview.html A tutorial implementation: https://github.com/microsoft/vscode-mock-debug A real implementation: https://github.com/microsoft/vscode-debugadapter-node/blob/main/adapter/src/runDebugAdapter.ts Truffle's VSCode extension seems to use DAP with these capabilities (I'll try it in Neovim to make sure).

Not many DAP are implemented in Rust. But:

• debug_types could probably be used to check the DAP implementation.
• dap crate goes a bit further and actually implements some of the boilerplate like parsing/sending Content-Length, serializing from/to BufReader/BufWriter, etc.
• Here's a project using the above crate. It's a pretty simple setup, they just use a 3-state machine: https://github.com/pileghoff/retread/blob/main/src/app_state.rs . Each command handler is only a few lines.

Further investigation

Based on the latest state (iFrostizz:franfran/debugger-args), it seems that:

• The debugger does not actually run the debuggee, but rather replays a trace. This is not an issue, as only 2/41 methods make use of dynamic execution: SetExecution and SetVariable. The plus side is that this makes StepBack supported.
• It looks like the implementation is actually not modular; there is no client-server or frontend/backend distinction, querying is coupled with rendering (also, it is hardcoded TUI, there is no option for stdio). This might make it a bit harder to support alternative interfaces to the debugger.
  • Actually, coupled implementation seems like a lot more work IMO. You have to do all the UI stuff for like browsing the source code yourself, instead of just having headless state transition functions (functional core), which can be driven by a UI (imperative shell).
• Source mappings are not passed to the DebuggerArgs. This means breakpoints in source code (DAP SetBreakpoints; instruction-level breakpoint is SetInstructionBreakpoints) won't work, nor inlay hints / hover of variable values (DAP Variables), nor scopes (DAP Scopes), nor source-based navigation (DAP StepIn, StepOut, StepOver).

EDIT: Solidity's support is less than I thought: https://github.com/ethereum/solidity/issues/13720 https://github.com/ethereum/solidity/issues/9461 . I had a quick look at at the AST JSON for some contracts and it seemed borderline usable but IDK. I'm going to try Solidity Debugger Pro to see if it's actually workable.

[llllvvuu]

Actually I think the answer here is to wait for https://github.com/NomicFoundation/rethnet. It sounds like they are going to make it modular so it should be usable as a foundation for DAP. If they make it pure functional it will be perfect as then developers can supply our own state layer and resolvers for build artifacts + blockchain state.