fix: restore the server binary check broken by #18281 - #23370
Merged
ChayimFriedman2 merged 1 commit intoSep 15, 2026
Merged
Conversation
rustbot
added
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
ChayimFriedman2
approved these changes
Sep 15, 2026
Contributor
|
Please fix the issue link. |
`isValidExecutable` was synchronous until rust-lang#18281 made it `async` without updating its only caller. `!isValidExecutable(...)` has negated a Promise ever since, which is never false, so the check has silently done nothing for about 2 years. A bad `rust-analyzer.server.path` therefore failed with Cannot activate rust-analyzer extension: undefined naming neither the binary nor the setting, because vscode-languageclient rejects with a string rather than an Error. The probe command still runs and still logs a warning with the real reason. Also fixed some string messages that were hidden by the dead check: - missing space after `--version.`, plus a run of indentation pulled in by a line continuation inside the template literal - the bootstrap notification and the `trace.extension` deprecation message both pointed at `OUTPUT > Rust Analyzer Client`, which is now called `rust-analyzer Extension` This restores the behaviour from before that change, which I think is desirable. However, there are two (somewhat uncommon, IMO) things that can start failing _again_ as a result of restoring this behavior: - a `server.path` that does not exit 0 on `--version`, even if it speaks LSP fine. Yesterday that would log the warning and continue, and would work fine. Now it will give an error, which is probably what was originally intended there. - a relative `server.path`, since the probe runs in the extension host's working directory while the server is launched in the workspace folder.
devjgm
force-pushed
the
greg/ra-await-valid-executable
branch
from
September 15, 2026 20:17
85b3c94 to
c6219a5
Compare
Contributor
Author
|
Thanks. Link issues fixed. |
rustbot
removed
the
S-waiting-on-review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
isValidExecutablewas synchronous until #18281 made itasyncwithout updating its only caller.!isValidExecutable(...)has negated a Promise ever since, which is never false, so the check has silently done nothing for about 2 years.A bad
rust-analyzer.server.paththerefore failed withnaming neither the binary nor the setting, because vscode-languageclient rejects with a string rather than an Error. The probe command still runs and still logs a warning with the real reason.
Also fixed some string messages that were hidden by the dead check:
--version., plus a run of indentation pulled in by a line continuation inside the template literaltrace.extensiondeprecation message both pointed atOUTPUT > Rust Analyzer Client, which is now calledrust-analyzer ExtensionThis restores the pre #18281 behaviour, which I think is desirable. However, there are two (somewhat uncommon, IMO) things that can start failing again as a result of restoring this behavior:
server.paththat does not exit 0 on--version, even if it speaks LSP fine. Yesterday that would log the warning and continue, and would work fine. Now it will give an error, which is probably what was originally intended in Run subprocesses async in vscode extension #18281.server.path, since the probe runs in the extension host's working directory while the server is launched in the workspace folder.