You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I might be missing something here, but the Breakpoint type is for »Information about a Breakpoint created in setBreakpoints or setFunctionBreakpoints« while DataBreakpoint is for »Properties of a data breakpoint passed to the setDataBreakpoints request« and the BreakpointEvent is only for Breakpoint breakpoints. So it does not make sense to use BreakpointEvent for a change in a DataBreakpoint.
There is no DataBreakpointEvent. Is that an accidental omission?
I might want to create a data breakpoint based on a launch.json configuration option and inform vscode about it, so users can disable the breakpoint if they so choose (or for that matter, users might configure data breakpoints through the debug console instead of the vscode ui, and then I might also want to surface such breakpoints through vscode anyways).
Hi,
I am facing the same thing here.
Same issue appears as well between Breakpoint and FunctionBreakpoint, so we can't distinguish a new Breakpoint when sending this event. I guess it'll be similar with InstructionBreakpoint.
Hi, we are hitting a similar problem for a debugger that offers console commands to manage breakpoints, including data breakpoints. For data breakpoints we cannot make the UI aware of changes driven by the console.
There is SourceBreakpoint, FunctionBreakpoint, InstructionBreakpoint and DataBreakpoint for their respective breakpoint representation in requests, Breakpoint exists for responses and for BreakpointEvent as a generic interface for all kinds of breakpoints.
As it stands, Breakpoint only includes information for SourceBreakpoint (source, line, column etc.). This arbitrary limitation could be resolved by extending Breakpoint to include breakpoint type and function/instruction/data breakpoint details. Specifying that the lack of type represents a source breakpoint would maintain backwards compatibility.
This same issue was brought up in #406 as well where Connor Peet (@connor4312) closed it for lack of interest, probably missing this 5 year old issue.
Activity
yannickowow commentedon Nov 28, 2020
Hi,
I am facing the same thing here.
Same issue appears as well between Breakpoint and FunctionBreakpoint, so we can't distinguish a new Breakpoint when sending this event. I guess it'll be similar with InstructionBreakpoint.
jreineckearm commentedon Aug 30, 2023
Hi, we are hitting a similar problem for a debugger that offers console commands to manage breakpoints, including data breakpoints. For data breakpoints we cannot make the UI aware of changes driven by the console.
samisalreadytaken commentedon Jan 20, 2025
There is
SourceBreakpoint,FunctionBreakpoint,InstructionBreakpointandDataBreakpointfor their respective breakpoint representation in requests,Breakpointexists for responses and forBreakpointEventas a generic interface for all kinds of breakpoints.As it stands,
Breakpointonly includes information forSourceBreakpoint(source, line, column etc.). This arbitrary limitation could be resolved by extendingBreakpointto include breakpoint type and function/instruction/data breakpoint details. Specifying that the lack of type represents a source breakpoint would maintain backwards compatibility.This same issue was brought up in #406 as well where Connor Peet (@connor4312) closed it for lack of interest, probably missing this 5 year old issue.