microsoft / microsoft/debug-adapter-protocol

Clarifying 'loadedSource' events

Open
#588 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
1.8k
Forks
173
Avg merge
7d 7h
Merged PRs (30d)
2

Description

I'd like to better understand when I should fire a 'loadedSource' event.

If an adapter has the supportsLoadedSourcesRequest capability set, should I also send the 'loadedSource' event whenever I find a new source or should I delay sending any events until after the first 'loadedSources' request has been made?

At least from my testing I've seen the following DAP messages:

  • initialize <>
  • launch <>
  • setBreakpoint... <>
  • configurationDone <>
  • loadedSources <>

In lldb-dap at least we know some information about the sources for the debuggee around the time of the launch request but I'm not sure if I should send 'loadedSource' events before the first 'loadedSources' request, or if that request will just write over any sources I've already sent.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the DAP definitions for supportsLoadedSourcesRequest, loadedSources, and loadedSource, then trace the initialize, launch, configurationDone, and loadedSources sequence described here. Compare the event-ordering rules with the behavior expected from lldb-dap; done means the protocol documentation clearly states whether loadedSource events may precede the first loadedSources request and how clients should reconcile them.

Written by the indexing model from the issue text.

Assessment

Domain
api, devtools
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.