Add a DAP server for IDEs to interact with #5394
Assignees
Labels
Comments
7 tasks
sdankel
added a commit
that referenced
this issue
Feb 20, 2024
## Description Related FuelLabs/sway-vscode-plugin#166 Adds a [DAP](https://microsoft.github.io/debug-adapter-protocol//) server as a new forc plugin, `forc-debug`. This enables a UI debugging experience in IDEs such as VSCode. For now, only debugging forc tests is supported. Users can: - set breakpoints inside of forc tests - step through the test, one VM instruction at a time, or continue to the next breakpoint - debug through multiple tests sequentially - see the VM register values in the IDE while debugging - see the current VM opcode, its inputs, and/or immediate value when when the VM is stopped ### Screenshots https://github.com/FuelLabs/sway/assets/47993817/24e2016c-d96c-4ef6-931f-8a4ce4f1386b https://github.com/FuelLabs/sway/assets/47993817/5f0fed49-b278-4074-a1a1-d37de00776f8  ### Local testing 1. Install `forc-debug` 2. Copy this sample launch.json in the VSCode workspace with sway code to debug: ```json { "version": "0.2.0", "configurations": [ { "type": "sway", "request": "launch", "name": "Debug Sway", "program": "${file}" }] } ``` 3. Follow [the steps](https://github.com/FuelLabs/sway-vscode-plugin/blob/master/docs/testing.md) for testing the VSCode extension ### Limitations - Breakpoints only work inside of the project/workspace being debugged - Stack trace support is limited - Not every line has source maps. Once debugging, "verified" breakpoints will show red and "unverified" (no source maps) will be greyed out. - Watch/repl expressions are not yet supported - Step into/out of is not supported - If you click "step over" many times in rapid succession, the server takes a while to catch up. Closes #5394 ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Vaivaswatha Nagaraj <[email protected]> Co-authored-by: Vaivaswatha N <[email protected]> Co-authored-by: IGI-111 <[email protected]> Co-authored-by: João Matos <[email protected]> Co-authored-by: Joshua Batty <[email protected]> Co-authored-by: Igor Rončević <[email protected]> Co-authored-by: Sudhakar Verma <[email protected]> Co-authored-by: Marcos Henrich <[email protected]> Co-authored-by: jjcnn <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should add a command like
forc debug servethat starts a DAP server for the LSP to communicate with. The server will be essentially a passthrough to the fuel core client, which has DAP-like APIs in its graphql interface.The IDE extensions can then use the same binary to start the DAP server, so the user only has to have 1 binary for both CLI-based debugging and IDE-based.
The text was updated successfully, but these errors were encountered: