setBreakPointsRequest argument for source.name is no longer defined

[weinand]

From @StephenBloomquist on April 6, 2017 16:54

As the subject says. The incoming DebugProtocol.SetBreakpointsArguments is now giving me an undefined source name. The path remains unaffected.

This might be related to VSCode 1.11.1 as I only just started experiencing this problem with no change on my end.

Copied from original issue: microsoft/vscode-debugadapter-node#109

[weinand]

From @Gama11 on April 15, 2017 14:59

We're having the same issue in vshaxe-debugadapter (vshaxe/flash-debugger#12), where setting breakpoints is broken with VSCode 1.11.x, but still works fine in 1.10.x, because the adapter assumes arguments.source.name to be present. The issue can still be reproduced in the latest Insider's build (9530cf6e2b).

[weinand]

From @Gama11 on April 15, 2017 15:4

This seems like a bug - despite name being optional in Source, it's specified to always be included in messages sent by the debug adapter:

Every source returned from the debug adapter has a name. When sending a source to the debug adapter this name is optional.

(https://github.com/Microsoft/vscode-debugadapter-node/blob/438678c7e2e4267b1df18b98234162d4fa450c8e/protocol/src/debugProtocol.ts#L1087-L1088)

[weinand]

@isidorn did this change for a reason?

The spec says "When sending a source to the debug adapter this name is optional." So DAs must deal with the fact that the name is not defined.

[StephenBloomquist]

My interpretation of the spec was the same as @Gama11. I assumed that it's saying the name is optional for a source sent from my side to the VSCode side (such as sendResponse()), and that it's always defined when sent from the VSCode side to my side (such as setBreakPointsRequest()).

[weinand]

@StephenBloomquist That interpretation isn't correct and doesn't make a lot of sense if you think about it: VS Code can only send back a name to the DA if it has gotten a name from the DA first. VS Code cannot "create" those names on its own because it does not understand the particular semantics of the name. The generic VS Code debugger is just a dumb UI for information provided by the DA. The DA "rules".

But we will try to restore the previous behavior if this can avoid any breakage.

[StephenBloomquist]

@weinand I'm not sure I entirely understand the reasoning here. Doesn't setBreakPointsRequest happen as a result of VSCode having "X, Y, Z" breakpoints set on "File"? Why wouldn't the adapter have all the file information? Is there a situation where one can set standard breakpoints in the VSCode UI without the context of a file?

[weinand]

Setting breakpoints is not tied to "files". For example in node-debug you can set breakpoints in internal scripts or evaluated strings that have no representation in the file system. If you stop in this code, the debug adapter (DA) returns in the call stack frames a name and a synthetic path (or reference number) of the code location. The path has no meaning to VS Code (so VS Code can not map it to a file in the workspace). But VS Code uses the path to load the content from the DA into a (readonly) editor where the user can set a breakpoint. In this case VS Code calls setBreakPointsRequest for the synthetic path (and optionally sends the name too). Only the DA knows what this path means (because it had previously handed out the path).

[isidorn]

I have pushed a commit which should revert this behavior and go back to the old way.