Panic when in a Cargo workspace

[tomaka]

I'm not sure whether I should report this in this repo or in the VSCode plugin repository.

When I'm working on a file of a library that is part of a Cargo workspace, VSCode shows me this output for the RLS:

thread '' panicked at 'could not run cargo: manifest path d:\Projets\vulkano\Cargo.toml is a virtual manifest, but this command requires running against an actual package in this workspace', src\libcore\result.rs:859

[Arzte]

Seems to be a vscode problem, I can reproduce it with vscode and current master 2c11ee5. It does not reappear when using other editing clients/plugins such as the Language Server for neovim.

[radix]

I'm using vscode-rust with freshly installed RLS and I'm getting this problem when I try to format my files, however it does seem that analysis/code completion is working.

[sophiajt]

@tomaka - do you have a project that repros this?

Does it also happen with our vscode plugin? (https://github.com/jonathandturner/rls_vscode)

[radix]

as I understand it, vscode-rust uses the rls_vscode code. My project pandt can repro it (github.com/radix/pandt), I added a rls.toml file at the root directory that enabled unstable features and tried to run Format Document and got this error.

[sophiajt]

@radix - in trying some of the radix/pandt subprojects I'm seeing some issues where the rls can't quite handle the projects. If the compiler part of rls fails, then a lot of the features don't work.

@tomaka - I saw this with the project @radix also mentioned. Currently, the RLS doesn't work with a "project of projects" style. You have to point it at the subprojects themselves.

[tbg]

What's perhaps an "easy win" here is to not silently swallow that error. You would not expect the happy status bar in this situation.

[nox]

What can we do to get progress on this?

[nrc]

@nox: @Xanewok is working on this as we speak! It might take a while to see visible results (we need to make some big changes under the covers), but progress is happening

[damienstanton]

I'm here from a bug I filed for the vscode-rust extension.

In case it helps, I am still getting errors even when isolating to one cargo project (I was indeed trying project-of-projects before).

RLS logs:

Missing change, aborting. Found 2, expected Some(10)
[Error - 10:05:35 AM] Connection to server got closed. Server will not be restarted.

and the Rust logging output:

DEBUG: RlsMode: start: rlsPath=rustup 
DEBUG: RlsMode: start: env={} 
DEBUG: RlsMode: start: args=["run","nightly-x86_64-unknown-linux-gnu","rls"] 
DEBUG: RlsMode: start: revealOutputChannelOn=3 
DEBUG: RlsMode: start: Language Client Manager: start

[emk]

I seem to be getting OK results if I isolate code to a single subproject, but there were errors on the first run that I don't seem to be able to reproduce right now. Now I just see "Analysis Finished" on the subproject, and things seem to mostly work.

When run on the subtitles-rs workspace, I get the same errors as everybody else:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: CargoError(Msg("manifest path `/home/emk/w/src/subtitles-rs/Cargo.toml` is a virtual manifest, but this command requires running against an actual package in this workspace"), State { next_error: None, backtrace: None })', /checkout/src/libcore/result.rs:860:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "PoisonError { inner: .. }"', /checkout/src/libcore/result.rs:860:4
[Error - 08:20:21] Connection to server got closed. Server will not be restarted.

Of course, isolating to a single subproject can be frustrating, because then I need to open lots and lots editor windows and Alt-Tab between them. And the project-of-projects design is very tempting in Rust, particularly when the subprojects are reusable, because it drastically reduces compile-times.

[AndrewGaspar]

Just pinging this thread - fixing this bug would be a huge quality of life improvement for me.

[Xanewok]

There is a workspace mode implemented now, with #462 being the last PR (as of now, still needs more work) to further the workspace support.

You can turn it on using "rust.workspace_mode": true (needs also "rust.unstable_features": true). If you want to specifically work only on a single package, set "rust.analyze_package" config key to the name of the single package you can work on.

With the workspace mode on, the RLS should not panic anymore inside of a workspace and report diagnostics for every package it needs. However, the save-analysis part still requires more work, as rls-analysis now can only host data in a per-crate fashion, whereas a single crate can have multiple save-analysis data (e.g. coming from lib or bin targets).

[AndrewGaspar]

Ah, I had tried enabling rust.workspace_mode, but didn't know about rust.unstable_features. I'll give this a try when I have the chance.

Thank you!

[nrc]

This is basically fixed now. Tracking the final few issues in #132.