The new UX is that users can choose to profile until a certain breakpoint is hit. To make this work, we add an "enabled filter" to the breakpoint manager--a filter function that can be used to turn on or off user-defined breakpoints. We apply this filter to choose whether we `.enable()` (previously `.set()`) any new breakpoints the user adds, and use it to `.enable()` and `.disable()` (previously `.remove()`) existing breakpoints. (Fixes #415) The picker uses the framework we previously set up in 8e330bd. We add a new DAP message to get the breakpoints the target currently has; the VS Code API doesn't expose the DAP IDs of breakpoints, and querying the state of breakpoints is easier than manually managing their state using a DebugSessionTracker (and also has no runtime overhead). Some changes were made in the profile controller to only disable the Debugger domain if no breakpoints were set, and to automatically stop profiling as we send a "stopped" event to the UI. Note that we don't actually watch the CDP paused events--since we can still get instrumentation breakpoints, which we don't want to use to stop debugging. This also includes state fixes such that starting a profile when paused on a breakpoint will tell the UI that we resumed debugging, and as a side effet of the filter. (Fixes #416)

Tell vscode that the debugger has continued, and unverify breakpoints, while profiles run #416

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions