* Add support for DAP to use std for communication
* Add more descriptive error logs for DAP
* Implement handler for continued event
* Add PR feedback to handle_continued_event function
* Updated debugger
* Fix race condition when using late case debug adapters
The main thing this commit does is fix race conditions between a
dap client's event handler and sending a launch/attach request.
Some adapters would only respond to a starting request after the
client handled an init event, which could never happen because
the client used to start it's handler after it sent a launch request.
This commit also ignores undefined errors instead of crashing. This
allows the client to work with adapters that send custom events.
Finially, I added some more descriptive error messages and change
client's starting request seq from 0 to 1 to be more in line with
the specs.
* Get clippy to run successfully
* Add some function docs to dap client
* Fix debugger's highlight when stepping through code
Merging with the main zed branch removed a function that
the debugger panel relied on. I added the function back
and changed it to work with the updated internals of zed.
* Get clippy to pass & add an error log instead of using dbg!()
* Get sequence id to be incremented after getting respond and event
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
We have to read them as early as possible to make sure we support more debug adapters. Some of them wait before you handled the initialized event. That is also why I moved the launch/attach request to be directly after the initialize request. For example the xdebug adapter sends the initialized event only when you send the launch request, so before if we send the breakpoints and configuration is done requests the adapter would stop and all channels were closed.
Not all the debug adapters send the continue event so we couldn't determine that the thread state status was `running`. So we have to determine it our selfs if the thread state status did not change, if so we change the status to `running`.
This allows us to show the pause button when the thread state status is running, so you can pause the programs execution.
* Add support for DAP to use std for communication
* Add more descriptive error logs for DAP
* Implement handler for continued event
* Add PR feedback to handle_continued_event function
This fixes an issue that not all debuggers send the `thread` event and we assumed that we always know the thread inside the handling code of the `stopped` event.