service/dap: substitutePath and VSCode irrelevantly complaining about 'source' request

[polinasok]

Source request is not well documented, so it has not been clear to us when to expect it nor how to handle it. Microsoft devs once told me "This is triggered if the UI needs to open a source whose sourceReference != 0 (doesn’t exist on disk). For instance in JavaScript this can be hit if I break inside of “eval”’d code, which is created from a string and is not a file VS Code can open from the filesystem." So it seemed at first that this would not apply to Go.

However, this request has come up in a couple of contexts now:

1. When experimenting with displaying the stack on entry, I saw it get triggered for source filess "?" and "." Those usually also have nil function associated with them. It is also triggered for "", which is what is returned in place of "<autogenerated>" file values. Should we be skipping such stack frames altogether or returning a "source unavailable" error? I do not see a way to list the stack frame, but not have the editor try to open the source.

2. VS Code DAP does not map trimmed paths #2754 identified a case where a relative source path also caused a source request. It is not clear yet if this relative path came from the delve backend or was a result of a substitutePath mapping. We could try to sanity check for that in the code when returning stackframe paths.

   If we do still end up getting a source request for a relative or absolute file path, should we be attempting to return the actual source code? Is that ever a valid scenario? Or should we be just returning a more detailed error, requesting that users check their substitutePath mappings and other configuration attributes?

When a source request is issued, the editor will open a new file tab and display either the returned contents (empty for an empty no-op response) or an error.

[aarzilli]

If the IDE, which theoretically has access to the build configuration, doesn't know how a source file ended up inside a binary then Delve, which only reads the binary file, certainly wont. It wouldn't help in either of the examples, in (1) the source file doesn't exist, and in (2) the best we can do is substitutePath.

[polinasok]

In case of (1) there is no source anyway. We just need to either adjust the stack not to display the questionable frame and avoid the source request or show the frame and return a better message why frame source is not available when the request is made.

In case of (2), the IDE requests the source for a path that it got from the debugger in the previous message, not came up with on its own (like with setting breakpoints). A user could build through the IDE or externally and then the debug session just uses the exec mode. I think this might have been one of the reasons, the legacy adapter attempted to do automated path mappings. We have been asked if we plan to do anything similar in the dap server and save users the trouble of mapping things manually, which they don't always know to do or don't always do correctly. In this case, a good path mapping ahead of time would avoid the source request altogether. But in the absense of that, I was thinking maybe source can be like list in the dlv terminal, but I guess the actual source printing is done from the frontend, so that won't work unless the extension is willing to intercept. So I guess our only option is to change the source request handler to return an informative error. And maybe also log warnings when delve operates on relative paths.

[polinasok]

@suzmue @hyangah

[polinasok]

Another case where this triggers

With a program like the one in golang/vscode-go#130, use dlv config goroutineFilters -w userloc 0.