`unresolved extern crate` for test crate

[FichteFoll]

I'm using benchmarking on nightly through the test feature, which requires extern crate test in the code. However, rust-anaylzer always marks this as unresolved extern crate and I have seen no other reports of this,
so I'm asking here whether that is a bug from rust-analyzer that it doesn't know about this default crate or whether I did a misconfiguration by using nightly.

I am running Arch Linux and the LSP plugin for Sublime Text.

$ rust-analyzer --version
rust-analyzer ???????

$ pacman -Qs rust-analyzer
local/rust-analyzer 20201130-1
    Experimental Rust compiler front-end for IDEs

[bjorn3]

https://github.com/rust-analyzer/rust-analyzer/blob/10e3a9879c8714320f9a0729d647da7877f0a753/crates/project_model/src/sysroot.rs#L40 only lists core, alloc and std. Maybe test isn't included as it is an unstable crate?

[doivosevic]

same. can we please get a response on this?

[flodiebold]

only lists core, alloc and std. Maybe test isn't included as it is an unstable crate?

These crates are unconditionally added as dependencies to each crate, IIRC. We probably don't want to do that for test. The problem is that we can't deal with the "it's only a dependency if there's an extern crate declaration" logic, since we need a fixed crate graph.

[kawogi]

I wonder how/if rust-analyzer handles the no_std case. In this scenario the std entry would be unnecessary.

What would happen if the test crate was added to that list?

[flodiebold]

We don't handle the no_std case. In principle, we should be handling it the same way, yes.

Adding test to that list would mean you can just use test::* without an extern crate declaration, which is not how it works in rustc. It also probably means we'd always analyze the test crate, which would have a performance impact. It would probably not have terrible consequences, but considering the vast majority of crates does not use test, I'm not convinced it would be worth working around in this way before we fix it properly. (You can add unresolved-extern-crate to rust-analyzer.diagnostics.disabled to get rid of the error.)

[DJMcNab]

I think we meet the same issue in priroda (cc @bjorn3), where priroda depends on miri, which has extern crate rustc_mir and friends. In this case, our root crate also depends on these crates, which works fine. It would be nice if there was at least some workaround

(Could building a custom crate graph JSON work? It would be nice to have some way to manually specify 'miri' depends on the rustc private crates)

[bjorn3]

For rustc_* there is the rust-analyzer.rustcDev config that you can point to Cargo.toml inside a local rustc checkout.

[DJMcNab]

Yes, I do have that set up, and I think it's set up properly.

That works for the root crate (priroda), but it doesn't work for the dependency crate (miri)