Support repo-relative paths in `rust-analyzer.server.path`

[OmarTawfik]

The VS Code configuration rust-analyzer.server.path exists to use a local binary, which is great when testing stuff, and also when using from a dev container. However, it expects a full path, which doesn't work well with version-controlled binaries. For example, if I set it to:

    // relative to VS Code workspace/repo root
    "rust-analyzer.server.path": "bin/rust-analyzer",

The extension will fail, printing the following error to Rust Analyzer Client VS Code output channel:

INFO [1/12/2023, 7:10:00 PM]: Starting language client
INFO [1/12/2023, 7:10:00 PM]: Using server binary at bin/rust-analyzer
ERROR [1/12/2023, 7:10:00 PM]: Bootstrap error Error: Failed to execute bin/rust-analyzer --version. `config.server.path` or `config.serverPath` has been set explicitly. Consider removing this config or making a valid server binary available at that path.

I wanted to propose executing that command relative to the workspace directory, to allow users to specify paths that are relative to the repository they are working on, instead of forcing them to use machine-wide installations.

[lnicola]

If you can set PATH in your environment, that should also work.

[OmarTawfik]

@lnicola .. Thanks for the suggestion! But as it requires changing the environment BEFORE loading VS Code, I'm not sure it would be ideal/as easy for most use cases:

1. It won't work if people are switching between different projects in the same window (open recent/^R hotkey for example).
2. It would require much more complex setup in case of running remote containers, or using GitHub workspaces, etc...
3. In some cases, it would defeat the purpose of letting repositories specify their own paths/configs. i.e. if I already know the path to the repository-specific binary (without opening it first), I can already set my machine-local settings.json.

[OmarTawfik]

I think the fix would come to setting cwd in the spanSync() call on the following line to the value of workspace.uri.fsPath. I assume there are no further security concerns, if we also check the workspace.isTrusted flag. Please let me know if I missed something.

rust-analyzer/editors/code/src/util.ts

Lines 115 to 124 in a119352

	export function isValidExecutable(path: string): boolean {
	log.debug("Checking availability of a binary at", path);
	const res = spawnSync(path, ["--version"], { encoding: "utf8" });
	const printOutput = res.error && (res.error as any).code !== "ENOENT" ? log.warn : log.debug;
	printOutput(path, "--version:", res);
	return res.status === 0;
	}

[bjorn3]

I think you can set PATH using rust-analyzer.server.extraEnv, which can be put in the project specific configuration.

[OmarTawfik]

@bjorn3 thanks for the suggestion. can you please clarify? something like below won't work, since:

• It won't expand existin $PATH values.
• It won't still know how to resolve ${workspaceFolder}.

 "rust-analyzer.server.extraEnv": {
    "PATH": "$PATH:${workspaceFolder}/bin"
  }

[bjorn3]

I see, I assumed it would work.

[Veykril]

"rust-analyzer.server.path": "${workspaceFolder}/bin/rust-analyzer",

should work

[OmarTawfik]

@Veykril It does not. See logs below:

INFO [1/19/2023, 2:05:40 PM]: Starting language client
INFO [1/19/2023, 2:05:40 PM]: Using server binary at ${workspaceFolder}/bin/rust-analyzer
ERROR [1/19/2023, 2:05:40 PM]: Bootstrap error Error: Failed to execute ${workspaceFolder}/bin/rust-analyzer --version. `config.server.path` or `config.serverPath` has been set explicitly. Consider removing this config or making a valid server binary available at that path.

It has been a while since I worked with VS Code extensions, but my understanding is that VSCode itself does not resolve ${var} variables in settings.json before passing it to extensions. It only does so for tasks.json. It also doesn't provide an API for extensions to resolve such variables themselves. So that resolution would have to be implemented on rust-analyzer side, or as my initial suggestion, set cwd when executing that command to the workspace folder directly.

See this for more information: microsoft/vscode#2809

[Veykril]

Ah, apologies, we do support variable substitution (we re-implemented it), but we do it after spawning the server I think. That is, that should work but it currently doesn't.

[Veykril]

rust-analyzer/editors/code/src/ctx.ts

Lines 155 to 161 in 6e52c64

	const newEnv = substituteVariablesInEnv(
	Object.assign({}, process.env, this.config.serverExtraEnv)
	);
	const run: lc.Executable = {
	command: this._serverPath,
	options: { env: newEnv },
	};

Yep, we pull the server path first, then substitute the configs, that's the wrong order.

[OmarTawfik]

@Veykril thanks for explaining! I sent #13993 to fix it.