RLS fails to finish building

[jamesray1]

At the moment, restarting VS Code doesn't even work, let alone touch Cargo.toml, although each have worked before. I'll have to use cargo build until this is fixed or another workaround is found. After closing VS Code, instances of rls keep using RSS in the task manager (this shows about 20 minutes after closing VS Code):

I disabled and renabled this extension, and the RLS status changed to starting, then building, then nothing after a minute, while cargo build finishes in a second, with some errors. When I was enabling and disabling vscode-rust some settings were changed, e.g. Racer_completion (now disabled). I've also enabled Rust-client: Update on Startup.

On restarting the RLS status changed to Updating..., 5 minutes later, still the same, at which point my computer was lagging so I restarted VS Code, then it was OK.

Yikes, when I restarted again and ran cargo build, I got

[jray@jr-dl rl]$ cargo build
error: process didn't exit successfully: `rustc -vV` (exit code: 1)                                                                                                                                  
--- stdout
rustc 1.31.1 (b6c32da9b 2018-12-18)
binary: rustc
commit-hash: b6c32da9b0481e3e9d737153286b3ff8aa39a22c
commit-date: 2018-12-18
host: x86_64-unknown-linux-gnu
release: 1.31.1

--- stderr
error: failed to find a `codegen-backends` folder in the sysroot candidates:
* /home/jray/.rustup

Not sure why the codegen-backends went missing. Later I tried cargo build again and it finished (still with errors in my own project).

I had removed the toolchains from settings.json because I thought they were set by vscode-rust. My language mode was also JSON with comments, changed to rust.

You can disregard below.

[jray@jr-dl rl]$ rustup show
Default host: x86_64-unknown-linux-gnu

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.31.1 (b6c32da9b 2018-12-18)
[jray@jr-dl rl]$ rustup update 
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
316.6 KiB / 316.6 KiB (100 %) 231.8 KiB/s ETA:   0 s                
info: latest update on 2019-01-17, rust version 1.33.0-nightly (ceb251214 2019-01-16)
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: downloading component 'rust-std' for 'wasm32-unknown-unknown'
 10.0 MiB /  10.0 MiB (100 %) 416.0 KiB/s ETA:   0 s                
error: component download failed for rust-std-wasm32-unknown-unknown
info: checking for self-updates

       stable-x86_64-unknown-linux-gnu unchanged - rustc 1.31.1 (b6c32da9b 2018-12-18)
  nightly-x86_64-unknown-linux-gnu update failed - (rustc does not exist)

warning: tool `rustfmt` is already installed, remove it from `/home/jray/.cargo/bin`, then run `rustup update` to have rustup manage this tool.
warning: tool `cargo-fmt` is already installed, remove it from `/home/jray/.cargo/bin`, then run `rustup update` to have rustup manage this tool.

Did as suggested in the warnings, ran again:

[jray@jr-dl bin]$ rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: latest update on 2019-01-17, rust version 1.33.0-nightly (ceb251214 2019-01-16)
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: downloading component 'rust-std' for 'wasm32-unknown-unknown'
info: removing component 'rustc'
info: removing component 'rust-std'
info: removing component 'cargo'
info: removing component 'rust-docs'
warning: during uninstall component rust-docs was not found
info: removing component 'rust-std' for 'wasm32-unknown-unknown'
warning: during uninstall component rust-std was not found
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'
info: rolling back changes
error: could not rename component file from '/home/jray/.rustup/tmp/c3k6ky9ki90bh7w0_dir/bk' to '/home/jray/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/etc'
error: could not rename component file from '/home/jray/.rustup/tmp/scjifd2ur5vv_hqg_dir/bk' to '/home/jray/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/share/man'
error: could not rename component file from '/home/jray/.rustup/tmp/16fez5pkzrlna61f_dir/bk' to '/home/jray/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/share/zsh'
error: could not rename component file from '/home/jray/.rustup/tmp/uzue_bw2pjxwgmg__dir/bk' to '/home/jray/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu'
error: failed to install component: 'rust-docs-x86_64-unknown-linux-gnu', detected conflict: '"share/doc/rust/html"'
info: checking for self-updates

       stable-x86_64-unknown-linux-gnu unchanged - rustc 1.31.1 (b6c32da9b 2018-12-18)
  nightly-x86_64-unknown-linux-gnu update failed - rustc 1.33.0-nightly (ceb251214 2019-01-16)

cargo +nightly build in my project finishes.

Related: #491, #143

[Xanewok]

Uh, these are somewhat hard to follow. I understand that the sysroot might've been corrupted in some sense, judging by the compiler-backend error? Generally more errors are surfaced to the user in the recent extension - could you please try running it again with 0.6.1 version of the extension (to be sure, this one is rls-vscode, not vscode-rust) and see if it helps?

[jamesray1]

I haven't been using VSCode for development lately, and TBH can't be bothered to look into this. But I may use it again soon.

[McPrescott]

I had the same issues originally described. I attempted restarting Vscode, installing previous versions of this extensions, 0.6.1, 0.6.0, 1.5.x, to no avail. At this time I didn't realize that everytime I restarted Vscode a new rls process was being spawned, and the previous processes presisted. After killing the several rls processes the extension started functioning normally.