Start the VS Code DAP bridge from launch.json alone

[yuuu]

Summary

Connecting VS Code used to take two files: a tasks.json background task that started mrdbg --dap-port, and an attach config in launch.json that named it as its preLaunchTask. This PR cuts that down to a single launch.json entry.

vscode-rdbg's launch request runs the program named by rdbgPath. It passes that program --command --open --stop-at-load --host=H --port=P -- ruby script, then waits for two DEBUGGER: ... lines on stderr before attaching to H:P. mrdbg --open now behaves that way:

{
  "type": "rdbg",
  "request": "launch",
  "name": "Debug on device",
  "rdbgPath": "/path/to/build/host/bin/mrdbg",
  "debugPort": "localhost:12345",
  "script": "${file}",
  "env": { "MRDEBUG_HOST": "192.168.0.10", "MRDEBUG_PORT": "4711" }
}

Changes

• Options
  • --open/-O (previously rejected as unsupported) now marks a launch.
  • In a launch, --host/--port give the DAP listen address, not the device's.
  • rdbg's --command and --stop-at-load are accepted and ignored.
  • Everything after -- is collected and ignored. The program must already be waiting in binding.debugger.
  • Every value flag also accepts the --flag=value spelling.
• CLI.launch_dap
  • Finds the device from the environment, the same way a bare mrdbg does: MRDEBUG_SOCK, else MRDEBUG_HOST:MRDEBUG_PORT.
  • Waits for the device's entry stop, binds the DAP port, and only then prints DEBUGGER: Debugger can attach via TCP/IP (H:P) and DEBUGGER: wait for debugger connection....
  • Reports failures (no TCP debugPort, device unreachable) on stderr as Error: .... vscode-rdbg shows such a message and aborts the launch.
• CLI.serve_dap: the bridge loop now shared by the existing --dap-port attach path and the new launch path. The attach path now binds the DAP port before printing DAP bridge listening on, which closes a small race.
• MRDEBUG_HOST: new env var, also honored by a bare mrdbg. Default 127.0.0.1.
• DapBridge: refuses ,-prefixed expressions (rdbg's command syntax) without touching the device. vscode-rdbg sends ,eval $stdout.sync=true at the start of every launch session.
• Docs: README now documents the single-launch.json setup instead of tasks.json + preLaunchTask, and keeps the manual --dap-port + attach route. CLAUDE.md documents the vscode-rdbg contract this relies on.

Caveat

This relies on how vscode-rdbg internally launches rdbg (the argv shape and the stderr strings it matches, from src/extension.ts's launchOnConsole/runDebuggeeWithTCP). That is not a public API, so a vscode-rdbg update could break it. The manual attach route still works either way.

Test plan

• rake test:unit: 0 KO. New tests cover --open and --flag=value parsing, launch_dap's two failure paths, default_host, and the ,command evaluate refusal.
• rake test:smoke passes.
• End to end against a real mruby process waiting in binding.debugger (MRDEBUG_PORT). A Python script played vscode-rdbg's part: it spawned mrdbg with vscode-rdbg's exact argv, waited for the stderr lines, then connected and sent initialize, launch, ,eval, setBreakpoints, configurationDone, evaluate, continue (breakpoint hit), stackTrace and disconnect. All succeeded, and the program ran to completion.
• Try it in real VS Code with vscode-rdbg.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VTDDhUqXPJBvErqqWKwULV