[Debug Adapter Protocol] - Sending BreakpointEvent for new breakpoints do not work for data breakpoints

[theIDinside]

When attempting to inform VSCode that a new data breakpoint has been created, for instance by using the debug console (so it doesn't go through the normal route of clicking on the watch variables etc), VSCode never registers it in the "Breakpoints" list - it only seems to be able to register them if they are normal breakpoints (and as such contains the source information).

So for instance, if I set a breakpoint using the debug console;

{
  type: "event",
  event: "breakpoint",
  body: {
    reason: "new",
    breakpoint: {
      id: 6,
      verified: true,
      source: { name: "foo.cpp",  sourceReference: 0,  path: "/foo.cpp"  },
      line: 168,
      instructionReference: "0x402f2d",
    },
  },
}

Vscode will register it. However, the same can not be said for data breakpoints, which only contain an id and the verified field.

Can VSCode only show watchpoints if they have gone through the dataBreakpointInfo request - and if so, why?

[roblourens]

My interpretation is that the existing breakpoint event in DAP can't do this, it would have to be extended to let you send along the info from dataBreakpointInfo as well. Does that sound right?

[connor4312]

it would have to be extended

I concur

[theIDinside]

My interpretation is that the existing breakpoint event in DAP can't do this, it would have to be extended to let you send along the info from dataBreakpointInfo as well. Does that sound right?

Probably true. So a better place to request this feature would be in the DAP-github?

[connor4312]

Rob already moved this issue to the DAP repo 🙂

[theIDinside]

Rob already moved this issue to the DAP repo slightly_smiling_face

Thanks a bunch! I'm going to close this issue then.

[connor4312]

This issue is now on the DAP repo, so we should keep it open to track

[connor4312]

Supporting this is a bit ugly because we have no way to go backwards from a dataId to the relevant info that editors might need, such as a description or alternative accessTypes. So there are two options:

1. Also require properties DataBreakpointInfoResponse & DataBreakpoint from the DA
2. Add an additional method to look up information from a data ID

Neither are very nice. The latter is probably nicer, but I hesitate to add a whole other request for a very niche flow (we've had no other requests for this.)

Since this issue was written there have been additional capabilities added, under supportsDataBreakpointBytes, which might solve the use case to allow clients to implement the desired flows without additional protocol changes.