Rls: Error if a crate is in dev-dependencies and used under #[cfg(test)]

[gentoo90]

RLS shows error when I put rand crate into [dev-dependencies] and try to use it under #[cfg(test)]:
use of unstable library feature 'rand': use rand from crates.io (see issue #27703)
help: add #![feature(rand)] to the crate attributes to enable'

RLS cannot find a crate in [dev-dependencies] and used under #[cfg(test)]:

can't find crate for `<CRATE NAME>`

although cargo build and cargo test run successfully.
Cargo.toml:

[package]
name = "rls_rand_test"
version = "0.1.0"

[dev-dependencies]
tempdir = "0.3"

main.rs:

fn main() {
    println!("Hello, world!");
}

#[cfg(test)]
mod test {
    extern crate tempdir;
}

RLS commit fb63cd5
built against rustc 1.16.0-nightly (eedaa94e3 2017-02-02)~~

[KalitaAlexey]

@gentoo90,
What exactly don't you like?
To use rand, you should add a feature attribute.
It errors in #[cfg(test)] because RLS sets test flag.

[gentoo90]

I checked again with another crate. It's not only rand.
If I add any crate into [dev-dependencies] and try to use it inside mod test RLS shows the error

can't find crate for `<CRATE NAME>`

rand just happen to have a duplicate in standard library under feature gate so the error is different.

[KalitaAlexey]

@gentoo90,
Can you execute cargo fetch and try again?
It can't find the crate because it hasn't been downloaded.

Try add a crate to [dependencies].
You will get same error.

[gentoo90]

Can you execute cargo fetch and try again?

Done. Result is the same.

Try add a crate to [dependencies].
You will get same error.

When I move it to [dependencies] the error disappears after relaunching vscode.
And when I move the crate back to [dev-dependencies] and relaunch again, error comes back.

[KalitaAlexey]

@gentoo90,
It's is interesting.
I will check it.

[KalitaAlexey]

@gentoo90,
Which OS do you use?

[KalitaAlexey]

I am able to reproduce the problem on Linux.
I am to find reasons.

[jntrnr]

I've seen some issues with dependencies when I was playing with the rls over the weekend. It seems like sometimes changes aren't being picked up if you edit Cargo.toml. I had to shut down vscode and restart it (definitely something we should fix).

In the current RLS, code that uses cfg(test) should be included by default. This wasn't the case before.

[jonasbb]

@jonathandturner The first problem is that after a change to Cargo.toml cargo is never rerun to update the changed dependencies. This could be fixed if rls would knew about those changes to Cargo.toml. The two options I see there are either registering rls as a language server for toml files but ignore everything on them except for the "on save" or require the editor extension to send custom notifications for Cargo.toml edits. A bad workaround might also be to listen to file change events from the file system, but this would break the nice abstraction from lsp.

I think the other problem is that cargo has no option which combines test and check in (CompileMode)[https://docs.rs/cargo/0.16.0/cargo/ops/enum.CompileMode.html]. This would be needed such that cargo actually looks at the dev dependencies and resolves them. In the current state only rustc is told to look at the tests.

[jntrnr]

I was chatting with @nrc about adding file-watching so that changes to Cargo.toml would get picked up by the rls. It's definitely planned, but it's not in there, yet. In generally, it probably makes sense to watch any file that's in your project so that any change will also get pulled in and the rls has the best view of your project it can get.

[jonhoo]

I stumbled upon what is probably the same (as in, original) issue in the arccstr crate. I have an extern crate that is cfg guarded by both test and a feature with a dev-dependency, and rls also gives the "can't find crate" error.

Specifically, I have:

#[cfg(feature = "serde")]
extern crate serde;
#[cfg(all(test, feature = "serde"))]
extern crate serde_test;

With Cargo.toml:

[features]
default = ["serde"]

[dependencies]
serde = { version = "0.9.10", optional = true }

[dev-dependencies]
serde_test = "0.9.10"

This is unrelated to the file watching problem of course, but rls not picking up dev-dependencies, while also trying to compile with test seems like an issue...

[Eh2406]

Agreed, the file watching problem seems unrelated. (Although it does seem like a useful feature.) This problem is that crates that use dev-dependencies cannot be used with rls. The work around is to temporarily make them crates that do not use dev-dependencies and restart rls. The file watching feature would make the restart unnecessary, but still require unnecessary changing of Cargo.toml.

[jarcane]

I discovered the same problem when doing the Rocket tutorials with VS Code on Linux. It uses dev_dependencies to only enable the testing feature in dev, but this results in redline errors on imports of the use lines (though completion oddly seems to work anyway).

[nrc]

So updates:

• this is still a problem, in fact it may have got worse - Cargo is now panicking, and I think crashing the RLS, because it can't stat a fingerprint file.
• workaround is not to run with cfg test (i.e., set rust.cfg_test to false in VSCode settings)
• I have a branch which watches Cargo.toml and causes a full rebuild, should land soon.

[nrc]

@Xanewok I remember at some point you were touching on Cargo fingerprint issues, could this be resolved now? We're also now watching Cargo.lock/.toml for changes.

[rcoh]

Hello from 2018 -- I had this issue but the fix was actually setting rust.cfg_test to true (it's false by default in VSCode) in case anyone else runs into it.

[Michael-F-Bryan]

I've encountered this issue on both Windows and Linux whenever using a crate defined in dev-dependencies and importing it with #[cfg(test)] extern crate foo;. It goes away if I set rust.cfg_test to false, but this isn't ideal because RLS can't check tests.

[wycats]

I hit the same issue as most recently reported by @Michael-F-Bryan.

TL;DR when rust.cfg_test is true (necessary to have RLS support inside of tests), crates inside of dev-dependencies aren't found. It seems unrelated to #[cfg(test)] (I can reproduce both with and without).

[nrc]

iirc, a workaround is to use all-targets, rather than cfg_test. We'll try to fix this (iirc it was non-trivial), but the workaround is good in the short term

[Xanewok]

@nrc this should be fixed with https://github.com/rust-lang-nursery/rls/pull/801.

[nrc]

CLosed by #801