dataBreakpointInfo and setDatabreakpointsRequest needs new fields

[theIDinside]

dataBreakpointInfo request takes the following parameters:

interface DataBreakpointInfoArguments {
  /**
   * Reference to the variable container if the data breakpoint is requested for
   * a child of the container. The `variablesReference` must have been obtained
   * in the current suspended state. See 'Lifetime of Object References' in the
   * Overview section for details.
   */
  variablesReference?: number;

  /**
   * The name of the variable's child to obtain data breakpoint information for.
   * If `variablesReference` isn't specified, this can be an expression.
   */
  name: string;

  /**
   * When `name` is an expression, evaluate it in the scope of this stack frame.
   * If not specified, the expression is evaluated in the global scope. When
   * `variablesReference` is specified, this property has no effect.
   */
  frameId?: number;
}

As we can see, frameId has no effect when variablesReference is passed in.

However, frameId will never have an effect - with or without variablesReference, because setDatabreakpoints can not differentiate between a dataBreakpointInfo that took either a variablesReference or a frameId parameter. Unless the DAP implementer make dataBreakpointsInfo be the actual request that sets the bp, these two requests make no sense (when talking specifically about frameId).

One solution would be to add another field to the response in dataBreakpointInfo that signals what "kind" of dataBreakpointInfo request & response was sent and received. That way, when it's time for setDatabreakpoints request to roll in, the DAP implementation can inspect "should this be set for this frame (because frameId was passed in to the dataBreakpointInfo request, just prior to it) or should it evaluate it as global?".

There is a solution to this, currently for DAP-implementers - and that's to customize (and thus break) the DAP specification when it comes to these two requests, by adding their own fields. But that's not ideal; particularly when the spec does not mention that these requests are runtime specific, which is the case for things like attach and launch requests respectively. The best approach would be if it was standardized in the spec.

This means adding a field that signals if a variablesReference or a frameId was used, to either the dataBreakpointInforesponse or the DataBreakpoint type that later is also sent via setDataBreakpoints request.

That way, when the DAP-implementer receives a setDatabreakpoints request, it can read the frameId and set the watchpoint for that particular frame.

[connor4312]

because setDatabreakpoints can not differentiate between a dataBreakpointInfo that took either a variablesReference or a frameId parameter

I don't think this is the case. DataBreakpointInfoResponse contains the adapter-defined dataId property, which is a string. The DataBreakpoint in SetDataBreakpoints then requires the dataId. It's up to the adapter to encode any necessary correlation they need into the data ID. For example, they might maintain a random map of UUIDs, or actually encode the frame ID along with other information as a JSON string inside the data ID.