Allow resolving the source location of stack frames as needed

[testforstephen]

Use Case: When the debugger stops at a breakpoint, the DAP requests the stackTrace with the source and line information. This works fine when the source code comes from existing files, but it causes problems when the source code is missing and has to be generated from disassembly tools.

The problem is that the decompiled code has different line numbers than the original source code, which leads to a mismatch when debugging with the decompiled source. The current workaround for the Java debugger is to decompile the sources of all the stack frames of the paused thread before sending them to the client, and to adjust the original line numbers of the stack frames to match the decompiled ones. The drawback of this approach is that it requires decompiling all the stack frames beforehand, which makes the frames request much slower.

Proposal: A possible solution is to add a new DAP request called resolveStackTrace. If a stack frame is marked as resolved, it means that it has the correct source and line information. The client can open and view it as usual. If a stack frame is marked as unresolved, the client has to resolve it first before opening it.

interface StackFrame {
  ...
  /**
   * If true, the source and line has been resolved and you can view its source directly.
   * Otherwise, the client will send another request to resolve the
   * source line first when you opens it.
   */
 isResolved: boolean;
}

/**
 * Resolve the stack trace information such as source and line.
 */
interface ResolveStackTraceRequest extends Request {
  command: 'resolveStackTrace';
  arguments: ResolveStackTraceArguments;
}

interface ResolveStackTraceArguments {
  frameId: number;
}

interface ResolveStackTraceResponse extends Response {
  body: {
    stackFrame: StackFrame;
  };
}

// cc: @isidorn @akaroml @nickzhums @jdneo

[isidorn]

also fyi @connor4312

[fbrosseau]

I had this related suggestion a while back: #189

[roblourens]

But the source and line can be displayed before the frame is "opened", would it display the wrong value until I click on it?

[connor4312]

I think the way this would be done is a client capability like supportsLazyStackFrames, and if that's true then location properties can be omitted from the StackFrame and accessed in some separate stackFrame request.

Curious to hear if any other DAP implementors/consumers have found a need for this.

[testforstephen]

But the source and line can be displayed before the frame is "opened", would it display the wrong value until I click on it?

A possible strategy is to show the source and line information in the initial stacktrace response, if available. However, when the frame is opened, the cursor should move to the final resolved source and line, even if they are different from the displayed ones. This discrepancy is acceptable for our cases.

[puremourning]

One problem with this: Lack of source:line information in the stack trace is a visual indicator that debug info was not available for that frame. Users use this cue to mentally skip frames and/or adjust their configuration/path mappings.

If we start rendering stacks with no source line info then users will be confused/unsure why.

[gregg-miskelly]

Curious to hear if any other DAP implementors/consumers have found a need for this.

In non-DAP scenarios, Visual Studio supports functionality like what is being proposed. It has not been an issue thus far for the C# debug adapters (coreclr and clr) but this is because we don't yet support decompilation in DAP-based scenarios. I think it would be useful when we add support.

[gregg-miskelly]

If we start rendering stacks with no source line info then users will be confused/unsure why.

I think we could fix this by differentiating between frames that can never have source information, and those which should have source information, but the process of doing so is potentially expensive, so we don't want to do it up front. A debug adapter should attempt to avoid marking a frame as 'resolvable' if in fact it can't do so.

[gregg-miskelly]

One nit on this proposal -- I don't think the new field on StackFrame should be called isResolved as all new DAP fields should have a 'falsey' default value.

[connor4312]

I've actually run into this recently as well when working on wasm in js-debug: to map locations, we need to disassemble the wasm to wat. This isn't super expensive but is still something that could be easily done more lazily.