bugfix: debug-completion depends on order of stackTrace being requested #6037
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mekpavit
force-pushed
the
bugfix/debug-completion-multiple-threads
branch
from
f6b8227
to
d815927
Compare
mekpavit
changed the title
mekpavit
force-pushed
the
bugfix/debug-completion-multiple-threads
branch
from
54dfa6e
to
29e8498
Compare
mekpavit
force-pushed
the
bugfix/debug-completion-multiple-threads
branch
from
29e8498
to
3d47aad
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some DAP client, when receiving Stoppage event, will get a list of all threads and iterate through that list to get each thread's stack-trace eagerly. One example of this is nvim-dap-ui.
Since metals maintains only the latest stack-trace response to use for frame-searching during debug-completion, debug-completion won't work if the frame-id in debug-completion request is not in the latest stack-trace response.
IMO, the behavior of debug-completion shouldn't depends on the order of stack-trace requests. And ideally, DAP server shouldn't even depends on the stack-trace being requested at all for debug-completion to work. However, since metals is currently just a proxy for scala-debug-adapter, I think the latter requirement can be relaxed.
So, this PR is trying to satisfy the first requirement where debug-completion will work regardless of the order of stack-trace requests. If DAP client, at least once, requests for the stack-trace, the debug-completion for any frame in that stack-trace will work.