RLS not installed message, but it is installed

[lily-mara]

I'm using version 0.4.10 of rls-vscode, and 1.29.1 of VSCode. I have disabled all extensions except rls-vscode. OS is macOS High Sierra.

When opening a rust project in VSCode, I see a message box saying "RLS not installed. Install?" and my only option is to click "Yes." However, I do have the RLS installed, and when I click "Yes", everything works as if the RLS was immediately found, and no extra install step happens.

If I do not click "Yes" on this box, the toolbar spinner stays in the "Starting" state forever.

The log to file feature does not provide any output.

[franky47]

I have the same issue, same setup (but on Mojave).

[nrc]

The check for the RLS is here: https://github.com/rust-lang/rls-vscode/blob/master/src/rustup.ts#L126 If you could debug the extension and find out what stdout is at that point, it would be really useful. Thanks!

[lily-mara]

"cargo-x86_64-apple-darwin (default)
clippy-preview-x86_64-apple-darwin (installed)
lldb-preview-x86_64-apple-darwin
llvm-tools-preview-x86_64-apple-darwin
rls-x86_64-apple-darwin (installed)
rust-analysis-x86_64-apple-darwin (installed)
rust-docs-x86_64-apple-darwin (default)
rust-src (installed)
rust-std-aarch64-apple-ios
rust-std-aarch64-fuchsia
rust-std-aarch64-linux-android
rust-std-aarch64-unknown-cloudabi
rust-std-aarch64-unknown-linux-gnu
rust-std-aarch64-unknown-linux-musl
rust-std-arm-linux-androideabi
rust-std-arm-unknown-linux-gnueabi
rust-std-arm-unknown-linux-gnueabihf
rust-std-arm-unknown-linux-musleabi
rust-std-arm-unknown-linux-musleabihf
rust-std-armebv7r-none-eabi
rust-std-armebv7r-none-eabihf
rust-std-armv5te-unknown-linux-gnueabi
rust-std-armv5te-unknown-linux-musleabi
rust-std-armv7-apple-ios
rust-std-armv7-linux-androideabi
rust-std-armv7-unknown-cloudabi-eabihf
rust-std-armv7-unknown-linux-gnueabihf
rust-std-armv7-unknown-linux-musleabihf
rust-std-armv7r-none-eabi
rust-std-armv7r-none-eabihf
rust-std-armv7s-apple-ios
rust-std-asmjs-unknown-emscripten
rust-std-i386-apple-ios
rust-std-i586-pc-windows-msvc
rust-std-i586-unknown-linux-gnu
rust-std-i586-unknown-linux-musl
rust-std-i686-apple-darwin
rust-std-i686-linux-android
rust-std-i686-pc-windows-gnu
rust-std-i686-pc-windows-msvc
rust-std-i686-unknown-cloudabi
rust-std-i686-unknown-freebsd
rust-std-i686-unknown-linux-gnu
rust-std-i686-unknown-linux-musl
rust-std-mips-unknown-linux-gnu
rust-std-mips-unknown-linux-musl
rust-std-mips64-unknown-linux-gnuabi64
rust-std-mips64el-unknown-linux-gnuabi64
rust-std-mipsel-unknown-linux-gnu
rust-std-mipsel-unknown-linux-musl
rust-std-powerpc-unknown-linux-gnu
rust-std-powerpc-unknown-linux-gnuspe
rust-std-powerpc64-unknown-linux-gnu
rust-std-powerpc64le-unknown-linux-gnu
rust-std-powerpc64le-unknown-linux-musl
rust-std-riscv32imac-unknown-none-elf
rust-std-riscv32imc-unknown-none-elf
rust-std-s390x-unknown-linux-gnu
rust-std-sparc-unknown-linux-gnu
rust-std-sparc64-unknown-linux-gnu
rust-std-sparcv9-sun-solaris
rust-std-thumbv6m-none-eabi
rust-std-thumbv7em-none-eabi
rust-std-thumbv7em-none-eabihf
rust-std-thumbv7m-none-eabi
rust-std-wasm32-unknown-emscripten
rust-std-wasm32-unknown-unknown
rust-std-x86_64-apple-darwin (default)
rust-std-x86_64-apple-ios
rust-std-x86_64-fuchsia
rust-std-x86_64-linux-android
rust-std-x86_64-pc-windows-gnu
rust-std-x86_64-pc-windows-msvc
rust-std-x86_64-rumprun-netbsd
rust-std-x86_64-sun-solaris
rust-std-x86_64-unknown-cloudabi
rust-std-x86_64-unknown-freebsd
rust-std-x86_64-unknown-hermit
rust-std-x86_64-unknown-linux-gnu
rust-std-x86_64-unknown-linux-gnux32
rust-std-x86_64-unknown-linux-musl
rust-std-x86_64-unknown-netbsd
rust-std-x86_64-unknown-redox
rustc-x86_64-apple-darwin (default)
rustfmt-preview-x86_64-apple-darwin (installed)
"

[lily-mara]

Changing a setting: "rust-client.rls-name": "rls" from rls-preview fixes this issue for me.

[Xanewok]

Default should be already set to rls per https://github.com/rust-lang/rls-vscode/blob/dca4451a0c94410bbfc558581972d4f39563807e/src/configuration.ts#L58
but we always set it to rls-preview via package.json
https://github.com/rust-lang/rls-vscode/blob/8c7f6133cf1dea4f8c168d91da4b6bb661c7a336/package.json#L221

[FliegendeWurst]

When will the fix be released (on the Marketplace)?

[lucyllewy]

this is broken again due to 4af0073 (might be my newness to rust.. looks like I installed a nightly build that doesn't have rls available - ref: https://github.com/rust-lang/rls/blob/master/README.md#error-component-rls-is-unavailable-for-download-nightly)

[Xanewok]

Tomorrow's nightlies should have the rls component back - rust-lang/rust#59279 (comment)

[FliegendeWurst]

Yes, but the rls-preview component is not available.

[gulshan]

Still getting
error: component 'rls' for target 'x86_64-unknown-linux-gnu' is unavailable for download for channel 'nightly'

[FliegendeWurst]

Try installing an older (< 2019-03-23) nightly version. You can check which tools are available in which nightly version here: https://rust-lang-nursery.github.io/rust-toolstate/

[brennie]

I am still hitting this with rust-client.channel set to "beta"

[mickdekkers]

I was getting this error too. In my case it turned out to be because I had set a specific nightly as default in rustup (nightly-2020-01-08), but I had the rust-client.channel setting set to nightly. Because of this, the extension was looking for the RLS for nightly, even though it was already installed for nightly-2020-01-08.

The documentation for the rust-client.channel setting states (emphasis mine):

Rust channel to invoke rustup with. Ignored if rustup is disabled. By default, uses the same channel as your currently open project.

So I removed the "rust-client.channel": "nightly" setting to reset it to the default behavior, and now it is able to find and use the installed RLS just fine.

This behavior is a bit confusing, but there's an open PR (#712) to make the default behavior an explicit setting at least.