Clangd extension stopps working on a remote developement setup

[yanggehua]

• VSCode Version: Version: 1.46.0-insider (user setup)
  Commit: 288852d
  Date: 2020-05-12T05:43:31.363Z
  Electron: 7.2.4
  Chrome: 78.0.3904.130
  Node.js: 12.8.1
  V8: 7.8.279.23-electron.0
  OS: Windows_NT x64 10.0.18363

• OS Version: Windows 10

Steps to Reproduce:

1. Open VS Code insider
2. Got notification "The Clangd language server was not found on your PATH. Would you like to download and install clangd 10.0.0". Source: clangd (extension). The only choice is INSTALL button (see screen shot)
3. Click INSTALL. The installation completed without any issue.
4. Click Reload Window. VS Code insider restarts, but got the same notification in Step 2. Click INSTALL will go back to step 3.

Meanwhile, clangd extension stopps working. It was fully functional yesterday. Screenshots with REMOTE and WORKSPACE Clangd settings.

Does this issue occur when all extensions are disabled?: Yes/No

[yanggehua]

Well, It's very likely the Clangd extension issue. I open the ticket there as well.

[alexdima]

👍 Let's first let the devs of the clangd extension investigate and they can determine if this is somehow caused by vscode.

[sam-mccall]

@alexdima You're probably right, but I'm not sure...

The issue here (at least, one of them) is clangd is writing a setting to ConfigurationTarget.Global (i.e. ~/.config/Code/User/settings.json). However the setting is machine-specific, so should be in ~/.vscode-server/data/Machine/settings.json. I can't find a ConfigurationTarget that does that, though. Am I missing something?

[alexdima]

@sam-mccall Thank you for the extra information.

[sam-mccall]

To clarify, I don't think VSCode has enough info to know the setting is machine-specific - a nice fix would be to provide a ConfigurationTarget.Machine or something that we could use.
But it's also fine if we need to detect that we're running remotely and do something special.

[yanggehua]

It seems clangd extension people are aware of this issue (see ticket). No need to track it here.

[sam-mccall]

@yanggehua I'm the clangd extension people, please don't close this bug (reopen if you can).

The vscode-clangd behavior you reported in clangd/vscode-clangd#25 is caused by an interaction of 2 bugs. One of them we can fix in our extension (clangd/vscode-clangd#26) but I think the other needs support from vscode I believe (see my comment above: #97616 (comment))

[alexdima]

Let's keep it open until @sandy081 has a chance to weigh in...

[sandy081]

@sam-mccall to summarise you are writing the machine specific setting using the API and it is being written into user settings instead of remote ?

Here is the issue tracking that feature - microsoft/vscode-remote-release#1801

If there is no other requirements we can close this as dup of #1801

[sam-mccall]

@sandy081 I think this is probably a dup of 1801, though I'm not 100% sure from the wording there.

writing the machine specific setting using the API

Yes, we're using vscode.workspace.getConfiguration('clangd').update('path', xxx, vscode.ConfigurationTarget.Global). "Global" doesn't really seem appropriate.

If there is no other requirements

The other thing is ideally this would be in both directions: if the extension is running locally and we apply the setting, it shouldn't apply to future remote sessions.

In our case the default is clangd.path=clangd, meaning locate our binary on the $PATH. If our extension running on machine X installs the binary and sets clangd.path to a concrete path, then the default on some other machine Y should still be to locate the binary on the $PATH. This is true whether X or Y or both are remote.

[sandy081]

#1801 supports following

vscode.workspace.getConfiguration('clangd').update('path', xxx, vscode.ConfigurationTarget.Global)

if clangd.path is machine scoped, then

• writes into global user settings in local window
• writes into remote user settings in remote window

Let me know if this covers your case?

[sam-mccall]

if clangd.path is machine scoped

I don't know what this means... Would it be a new piece of metadata I can specify in package.json where the setting is defined? As long as the extension author can control it, this makes sense to me 👍

writes into global user settings in local window

Ideally not: if it's a machine-specific setting, then it should only affect the local machine, not global to any machine I subsequently connect to. But if VSCode doesn't have a per-machine config for the local machine, then this is the next best thing and I can document the workaround.

[sandy081]

I don't know what this means... Would it be a new piece of metadata I can specify in package.json where the setting is defined?

Yes, you can define the scope of the configuration to machine in package.json. Please refer to the docs here - https://code.visualstudio.com/api/references/contribution-points#Configuration-property-schema

Ideally not: if it's a machine-specific setting, then it should only affect the local machine, not global to any machine I subsequently connect to.

I am sorry that I am bit cryptic before, assuming that you are aware of hierarchies. In VS Code user can define settings at following targets in Local and Remote workspace

• User
• Remote (only in remote workspace)
• Workspace

I would focus on first two (User & Remote) and let's consider a setting clangd.path that is defined as machine scoped.

• In a local workspace, this setting is applied if it is defined in User settings.
• In a remote workspace, this setting is applied if it is defined in Remote settings and the value defined in User settings is ignored.

So coming back to the feature that #1801 supports:

vscode.workspace.getConfiguration('clangd').update('path', xxx, vscode.ConfigurationTarget.Global)

If the extension uses above API from a

• Local workspace, VS Code writes the value into user settings
• Remote workspace, VS Code writes the value into remote user settings

So, I expect above support covers your scenario well?

[github-actions]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!