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)

[pymongo]

I think we need to add a config like rust-analyzer.rustcSource

"rust-analyzer.rustcSource": "/home/w/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/rustc-src/rust/compiler/rustc_driver/Cargo.toml"

rust-analyzer.rust_test_crate_source config example:

"rust-analyzer.rust_test_crate_source": "/home/w/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/test/Cargo.toml"

[workingjubilee]

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.

@flodiebold This is just my curiosity here but what constraints exactly require a "fixed crate graph"? I know about rust-analyzer's graph-query model in the broad sense, I'm not sure why that requires fixedness here.

[flodiebold]

What I meant by that is that we need to know the crate graph before analyzing the code, it can't change in response to things we find during name resolution. The reason for that is that the crate graph is an input for rust-analyzer. Of course nothing is impossible, this is just a simplifying assumption, but it's pretty pervasive, I think. I imagine it might be possible to solve this by instead having a "preliminary" crate graph as input, where possible sysroot dependencies are specifically marked, and then having name resolution (the crate_def_map query) also produce the actual dependencies. That would mean that we'd need to expand and name-resolve all crates to get the actual crate graph though, and I'm sure other parts of the code rely on the graph being free to compute, so then we'd have to check whether those parts can/have to use the preliminary graph, and so on.

[Walther]

Polite little bump 🙇‍♂️
Any updates on this - known workarounds, possible approaches for fixing this, other?

Ran into this when using cargo bench, rust-analyzer & vscode.

(You can add unresolved-extern-crate to rust-analyzer.diagnostics.disabled to get rid of the error.)

if i'm not mistaken, this disables all unresolved extern crate warnings, which is probably not an ideal user experience either.