-
Notifications
You must be signed in to change notification settings - Fork 168
RLS fails to start because of the nightly toolchain specified with date #503
Comments
As a workaround one can add By the way, this bug also appears when |
@JoshLambda The issue where it doesn't work if rust-client.channel is not set is fixed in 0.5.4 |
@angusgraham Thanks for the info, that's good to know. |
This should be fixed now, so closing. |
This is not fixed, I am currenlty having the issue on nightly 1.36. |
I'm having the same problem here VSCode 1.52.1 x64 ea3859d4ba2f3e577a159bc91e3074c5d85c0523 Rust Toolchains: |
VSCode
Version: 1.30.2
Commit: 61122f88f0bf01e2ac16bdb9e1bc4571755f5bd8
Date: 2019-01-07T22:49:48.319Z
Electron: 2.0.12
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
OS: Linux x64 4.15.0-45-generic
Rust Toolchains installed (by rustup)
stable-x86_64-unknown-linux-gnu
nightly-2019-01-15-x86_64-unknown-linux-gnu (default)
nightly-x86_64-unknown-linux-gnu
Description
The newest Rust nightly build is 1.34. However, this version seems to have no RLS server at present.
Therefore, I used 1.33 by specifying the date when doing
rustup toolchain install
.However, if keeping the
"rust-client.channel"
setting in VSCode as"nightly"
, the RLS cannot start as normal.I successfully started RLS by setting
"rust-client.channel": "nightly-2019-01-15"
. This setting was not prompted and treated as an unrecognized value.I guess the current rls-vscode implementation concats the "rust-client.channel" setting with other stuff like OS and architecture to produce the correct toolchain name, then finds the toolchain, and finally launches the RLS. However, some details like prompts and config validations are ignored.
The text was updated successfully, but these errors were encountered: