Rls: RLS is overwriting/competing with cargo CLI builds

[scottjmaddox]

RLS in VSCode just started competing with cargo CLI builds, ever since Rust 1.26 was released. If I let RLS run on a project, and then run cargo build from the CLI, then touch a file and let RLS run, then run cargo build again, I end up rebuilding from scratch.

On a related note, any time RLS is running, I now get Blocking waiting for file lock on build directory when trying to run a cargo command from the CLI.

This makes RLS completely unusable, since I'm constantly rebuilding from scratch and waiting on RLS before I can even start.

This is on MacOS 10.12.6. Please let me know what other information I can provide to help solve this problem.

[jonasbb]

This should not happen with the newest version of the VSCode extension, see bug #864. Anyway, the setting "rust.target_dir" should solve the problem.

[scottjmaddox]

Adding "rust.target_dir": "target/rls", to my VSCode settings appears to have fixed it. Thanks!

[thibautRe]

This setting doesn't seem to fix the issue for me.

I'm running VSCode RLS 0.4.3 and rust 1.26, I tried setting "rust.target_dir" to "target/rls" (which seem to be the default) as well as "../target/rls" (I'm running my binary crate in a workspace so I tried several things). RLS always seem to put the build files in "<root>/target/debug" (even after cleaning the target folder).

There might be something obvious that I'm missing but I can't see what.

[jonhoo]

Yeah, I'm seeing the same issue. It seems to be exaggerated by setting CARGO_TARGET_DIR to some single shared directory.

[tomjakubowski]

(I'm running my binary crate in a workspace so I tried several things)

A VSCode workspace?

I'm seeing the same issue, and changing "rust.target_dir" does not fix. I'm building a Cargo project within a VSCode workspace, but there is no Cargo workspace in play for me.

[thibautRe]

A VSCode workspace?

A Cargo Workspace, not a VSCode one. I open Code by running $ code . in the root of my cargo workspace.

Paging the issue https://github.com/rust-lang-nursery/rls-vscode/issues/311 where people seem to have the same issue.

[jonhoo]

For people not using VSCode (but, say LanguageClient-neovim), note that RLS does not actually accept a setting called target_dir. Instead, you must change the server command to something like:

    \ 'rust': ['env', 'CARGO_TARGET_DIR=/some/target/rls', 'rls'],

It's not ideal...

[Xanewok]

@jonhoo it does accept the parameter via LSP workspace/didChangeConfiguration
(Note that the the configuration is here on the server side), which serves as the primary means to announce the configuration to the language server.

(It seems that LanguagueClient-neovim implemented it in https://github.com/autozimu/LanguageClient-neovim/pull/179, might be worth taking a look, it looks like it needs a single config file in the workspace)

[jonhoo]

@Xanewok See my follow-up in https://github.com/rust-lang-nursery/rls/issues/870#issuecomment-389287265. Setting target_dir in settings does not seem to make a difference when CARGO_TARGET_DIR is set.

[scottjmaddox]

Well, setting target_dir is working in one project, but not another. It is working a project with a cargo workspace, though I'm not sure if that's the root cause of the difference. This definitely appears to be a rls-vscode issue, though, so I'll continue the discussion over there.

[scottjmaddox]

As mentioned above, I don't think I've changed anything, but now the target_dir settings no longer fixes it. At first, I assumed this was still a VSCode extension issue, but running rls --cli inside a new test project shows the same issue (rls building into target/debug, instead of target/rls). Unless that's expected behavior, and I'm missing some config, this seems to suggest the issue is with rls itself?

rls -V prints rls-preview 0.126.0-stable (f5a0c91 2018-03-26)

echo $CARGO_TARGET_DIR prints a blank line, so that doesn't appear to be the issue for me, either.

Edit:

Reverting to rust 1.25.0, then trying from the cli again fixes it:

$ rustup override set 1.25.0
info: using existing install for '1.25.0-x86_64-apple-darwin'
info: override toolchain for '/Users/smaddox/code/rust/test-rls-lib' set to '1.25.0-x86_64-apple-darwin'

  1.25.0-x86_64-apple-darwin unchanged - rustc 1.25.0 (84203cac6 2018-03-25)

$ rls -V
rls-preview 0.125.1-stable (cebf188 2018-03-19)
$ rls --cli
[output elided]
$ ls target
rls

So the issue definitely appears to be with rls.

[nrc]

We will address this by (hopefully) making a point release on the stable channel next week (https://github.com/rust-lang/rust/issues/50756)

[nrc]

In the meantime, I would recommend using beta or nightly channel RLS to avoid the bug. Sorry for the inconvenience.

[ririsoft]

Hello I have a workspace with 2 projects in it. I am using VSCode. Neither setting the rust-client.channel to nightly, nor rust.target to rls, nor rust.target_dir to rls fixes the issue. Do anyone has a trick to make it work again, please ? rls is unusable as is today due to constant rebuild of the full package dependencies and no more incremental build when switch from editor to command line. Thanks in advance !

[jonhoo]

@nrc I believe several of the users here, myself included, also observe this on nightly rls?

[Xanewok]

Apart from yet again premature fix (sigh) that is fixed in the recent 0.4.4 (https://github.com/rust-lang-nursery/rls-vscode/pull/316) version of the VSCode plugin, I think nightly users should not be affected. @jonhoo is it with CARGO_TARGET_DIR set?

[jonhoo]

@Xanewok yes, this is with CARGO_TARGET_DIR set. I'm also not using rls-vscode, just rls + a language client for neovim. I think rls should probably use a separate subdirecory by default so that we wouldn't have to override target_dir explicitly :)

[nrc]

Should be fixed now.

[jonhoo]

@nrc do you have a link to where the fix landed?

[nrc]

It was quite a while ago, sorry - it was only broken for a small window of time, we just got unlucky and picked a stable release from that window.