Rls: "Trying to build" Error being reported across OS's

[Dowwie]

"There was an error trying to build, RLS features will be limited. Try running cargo check for more information"

This error is being reported across IDEs, across operating systems. The error emerged within the last day or two. Something is wrong with a recently nightly update.

[karyon]

notably, cargo check does not find any issues.

[Carjay]

Same here after I updated to rustc 1.25.0-nightly (5313e8728 2018-02-17) on Linux.

I am not sure what the previous version was but I think I updated it only a couple of days ago so it can not be an issue for very long.

[karyon]

so, i tested this and with vscode setting "rust-client.channel": "nightly-2018-02-15" this error does not appear but with 2018-02-17 it does.

[nrc]

The error message is new, but it is unlikely to be false. Often the RLS would silently fail. If cargo check succeeds, could you try running cargo clean, then restarting your editor? It is possible that Cargo is being configured differently between the command line and the RLS. Do you have any configuration going on? What kind of project are you building? Does it have workspaces? A library and a bin in the same crates?

[karyon]

i installed everything just yesterday and am rather sure i had nothing manually configured at all. the project is rustfmt (which has workspaces but you probably knew that already ;) )

[nrc]

Thanks, I'll try and reproduce! I assume you're building Rustfmt with just a plain cargo check in the top directory?

[karyon]

yes.

[Carjay]

I now built rls from sources and found that the error occurs in my case because the manifest "Cargo.toml" cannot be found. This is expected since my folder is a top folder of several projects which does not have a "Cargo.toml" inside.

I knew that this is not fully supported (always got the WARN popup stating that some features will not work) but I did not assume that it would become an error.

I also bisected the commit that caused this message to show and it turns out to be https://github.com/rust-lang-nursery/rls/commit/f3967b5c201f600ff9208e20e0bfb03cd60dea19 (which is the commit that actually introduced this message).

The actual error occurs in this line:

https://github.com/rust-lang-nursery/rls/blob/4340c2d71d2857fb11c8d7e0f44899628353d55d/src/build/cargo.rs#L117

Because the manifest is not found, find_root_manifest_for_wd bails out in this line https://github.com/rust-lang/cargo/blob/489f570d47dea88d8f9a1205173d3e779e1a78e2/src/cargo/util/important_paths.rs#L33

[nrc]

@Carjay It is likely that before the error message you weren't getting much help from the RLS at all. The RLS only really works if you work on a single Rust project at a time. The error message is just telling you that explicitly.

[Carjay]

@nrc Ok, fair enough, thanks for the info.

I now switched to use separate vscode windows for each project and the message no longer appears.

[Michael-F-Bryan]

I'm having the same issue on a project which contains multiple Rust crates and a top level "virtual" Cargo.toml. Interestingly RLS was behaving just fine when I worked on any of the individual crates within my workspace.

The error message is just telling you that explicitly.

Is there a way to only show this error message the first time it occurs? Literally every time I type a letter a new copy of the same error message will pop up, which makes editing anything quite unbearable.

[nrc]

Tracking what can cause the error:

• [x] continuing to try and build deps once one dep fails
• [x] opening a directory without Cargo.toml (https://github.com/rust-lang-nursery/rls/issues/722#issuecomment-366549149)

[nrc]

@Michael-F-Bryan what project are you running into this with?

Is there a way to only show this error message the first time it occurs? Literally every time I type a letter a new copy of the same error message will pop up, which makes editing anything quite unbearable.

I've looked into this and it appears to be very tricky. I'll re-visit if I can't address some of the causes of these errors.

[nrc]

@karyon I could not reproduce using rustfmt master unless there is an error in one of the crates. What platform are you on? Is the build error free?

[Michael-F-Bryan]

@Michael-F-Bryan what project are you running into this with?

Unfortunately it's a project from work so I don't think I can share it. This is essentially just a normal workspace project, laid out something like this:

• project_root/
  
  
  
  • Cargo.toml
  
  
  • README.md
  
  
  • crate_a
  
  
  • Cargo.toml
  
  
  • src/
  
  
  • crate_b
  
  
  • Cargo.toml
  
  
  • src/
  
  

I'm on my work computer at the moment (x86_86 windows 10), but it also happens on my machine at home (Arch Linux).

Here is a minimal example where I was able to reproduce it. Unfortunately I don't know how to ask VS Code which version of RLS it is using under the hood.

[nrc]

@Michael-F-Bryan thanks for making the minimal example! I cannot reproduce the error though. I open project_root and the RLS builds and is done, then the RLS seems to work properly. I am OS X using the current master, which is fairly similar to current nightly, although there are some changes.

[nrc]

And now we should only show that error when the state changes from successful to unsuccessful.

These changes are all on master. I need to fix a bug I introduced along the way and then will push to Rust repo and into nightly, hopefully tomorrow or the next day.

[Michael-F-Bryan]

I enabled the log-to-file option for the RLS plugin, but it's not overly useful. Nothing gets written to the log file when that red error message pops up, although if you make a syntax error it'll log the usual rustc error message.

Is there any way to ask VS Code exactly which version of RLS it's running? From the command line if I run rls --version it shows rls-preview 0.125.0-nightly (f014911 2018-02-14), but I'm not sure whether that's current or if it's left over from when I tried falling back to the 2018-02-15 nightly...

[nrc]

The logging options are only useful if you also enable some logging when running the RLS (it's a standard env-logger setup). However, I don't think you'll see anything useful on nightly, you would need to have a self-built master.

You could try setting workspace_mode to true explicitly in the user settings (this is meant to be ignored, but it actually doesn't seem to be :-( )

[alsuren]

In my case, I think that the problem was caused by VS Code defaulting to the nightly toolchain for all projects, and trying to spin up the nightly version of RLS even for directories that rustup knows are using the stable toolchain.

The thing that tipped me off to this was that pgrep -fal rls showed the nightly executable. The fix was "rust-client.channel": "stable",. It might be a good idea to check that the toolchains match up early on, and warn specifically about the misconfiguration before continuing?

[nrc]

This mostly seems to be addressed now. If there are still bugs, please file a new issue.