handle unix file paths on Windows for setting breakpoints with dap

[repelliuss]

My DAP client sends file paths with forward slash on Mingw64 environment. I am not sure if DAP specification requires Windows paths being used but a quick search seemed not so.

Deep in the callstack there was a cache variable with sources to indexes and that cache had keys with Windows paths so my breakpoints weren't being set.

Aside from that, I have three comments.

1. I invested too much time for my symbols not being loaded. I saw PortablePDB functions but I didn't really think 'Portable' here was the new PDB format that should be generated through project settings. What I thought was, my PDB files are not embedded, and seperate, such that they can be moved so they are portable. Of course that is flawed but I think mentioning how PDB files must be generated in readme does not hurt.
2. Assertion at modules_sources:68 was failing but I didn't look further. It was working fine if disabled. Maybe you would be interested.
3. Interpreter protocol name vscode doesn't reflect its full capability and may make people think it only works for VSCode. Maybe use something like dap? I think lldb went through same thing with lldb-vscode to lldb-dap.

[viewizard]

For current debugger logic, DAP client must provide as source same file name/path as project have stored in generated PDB during project build, since path may be relative (at least debugger care abot this) and debugger could be started remotely (even on different OS) and know nothing about DAC environment and where (what OS) was used for DLL build.

For current debugger logic, breakpoints with paths ./a/b/source.cs and .\a\b\source.cs are breakpoints for different locations (different module), and this is correct behaviour, that should not be broken.

[repelliuss]

I don't get why relativity matters here. I did not really think the case of /a/b/c and \a\b\c being different locations so yeah this would err.

Though, I don't think you can expect DAP clients to inspect PDB files. This seems like the job of the debugger, although simple, and by DAP specification we aim to seperate these things, no? Even if they can inspect PDB files, how would they know where that PDB file would reside without also knowing the build system? They can only know the path of a file and that path style depends on the environment which they can't help with except maybe convert them to OS style (remote or not) and not the environment. If I am correct in my assumptions, they can't really handle /a/b/c and \a\b\c case, can they?

[viewizard]

DAC client provide path to file and line number for breakpoint (this is DAC client care, not debugger), debugger search in available PDB files and setup breakpoint in apropreate module code. /a/b/c and \a\b\c are different files locations in current debugger logic, that usually mean different modules, debugger can't figure out what DAC client want in this case at this point (breakpoint setup request) no mater could it inspect PDB file or not.

Not really sure about DAC clients work, but usually DAC client is part of something bigger, that also include build routine and debug session start and probably should know how DLL/PDB builds and what paths are stored.