vscode/clangd converts mapped drive to UNC path

[are-scenic]

Dev environment

Due to work-related policies and the nature of our development environment, I need to manage our codebase in a directory on a network drive. On Linux due to mount points I have no issue whatsoever. However, on Windows the closest thing to a mount point is either symbolic link or a mapped drive. We use the latter one. By the way, we can't use UNC paths directly because of the issues with the remote development. It's impossible to open a workspace directly from UNC path if you connect remotely, let's say using VSCode Remote Tunnel. We use CMake Tools extension to generate the compile_commands.json file for clangd.

Problem statement

If I use the Microsoft's own C/C++ extension for VSCODE, there is no issue to navigate through the code as Intellisence shows paths correctly. However, if I switch to the clangd extension, it converts mapped-drive to the UNC path to which this mapped drive has been mapped. It's not just a matter of convenience of having two open editors for the same file. If I use remove development, these UNC path conversions can't be even open for the reasons specified above. It makes code navigation impossible with clangd-extension. Important note: we checked the generated compile_commands.json file and it doesn't have any UNC paths, but only the mapped-drive paths.

References

Interestingly, there is another VSCODE extension that has a very similar bug ticket, see: https://github.com/microsoft/pylance-release/issues/5395

[are-scenic]

@HighCommander4, please, could you look at his issue. It's possible that the issue is in clangd and not the extension, but I don't have enough knowledge in it to be able to distinguish.

It's so painful to work with ms-vscode.cpptools, but because of this issue I simply can't switch back to clangd-extension.

Please help.

[HighCommander4]

I'm not a Windows user and this is the first I've heard of UNC. I don't think I'm a good person to investigate this.

If someone else would like to investigate it and has questions about clangd internals, I'm happy to try and help by answering them.

[are-scenic]

@HighCommander4 thank you for your response. I appreciate it a lot.

@sam-mccall and @hokein, I saw that you very prominent contributors to this project and also to clangd and LLVM. I really hope that you might be able to help with this one, please.

[sir-maniac]

I think it bears clarifying: Something is converting a mapped drive, like Z:\some\path to a windows network path, like \\server\some\path. Visual studio code interprets that path as invalid(at least when using an SSH remote), so links between files don't work.

[sir-maniac]

A potential fix would be to use --path-mappings, however clangd seems to behave inconsistently.

The path mapping option:

--path-mappings=\\10.0.2.1\devel=q:\

Here is a log entry where it works:

[11:25:44.726] --> textDocument/clangd.fileStatus
V[11:25:44.726] >>> {
  "jsonrpc": "2.0",
  "method": "textDocument/clangd.fileStatus",
  "params": {
    "state": "idle",
    "uri": "file:///q:/Source/Repos/DragonbornSpeaksNaturally/dsn_plugin/dsn_plugin/Equipper.h"
  }
}

And here is a request/reply for "textDocument/hover":

V[11:35:13.730] <<< {
  "id": 176,
  "jsonrpc": "2.0",
  "method": "textDocument/hover",
  "params": {
    "position": {
      "character": 7,
      "line": 1
    },
    "textDocument": {
      "uri": "file:///q%3A/Source/Repos/DragonbornSpeaksNaturally/dsn_plugin/dsn_plugin/Equipper.h"
    }
  }
}

I[11:35:13.730] <-- textDocument/hover(176)
V[11:35:13.751] ASTWorker running Hover on version 1 of q:\Source\Repos\DragonbornSpeaksNaturally\dsn_plugin\dsn_plugin\Equipper.h
I[11:35:13.765] --> reply:textDocument/hover(176) 35 ms
V[11:35:13.765] >>> {
  "id": 176,
  "jsonrpc": "2.0",
  "result": {
    "contents": {
      "kind": "markdown",
      "value": "### `PCH.h`  \n\n---\n```\n\\\\10.0.2.1\\devel\\Source\\Repos\\DragonbornSpeaksNaturally\\dsn_plugin\\dsn_plugin\\PCH.h\n```"
    }
  }
}