rust-analyzer
rust-analyzer copied to clipboard
"error: extern location for <crate> does not exist"
After an upgrade to a newer rust-analyzer version (the one that happens to be in nixpkgs unstable) I'm now getting a lot of error messages like these when starting up rust-analyzer:
error: extern location for serde does not exist: /home/grfn/code/readyset/readyset/public/target/debug/deps/libserde-62e997496fa5b83d.rmeta
--> /home/grfn/.cargo/registry/src/github.com-1ecc6299db9ec823/mysql-22.0.0/src/lib.rs:834:1
|
834 | pub extern crate serde;
| ^^^^^^^^^^^^^^^^^^^^^^^
There's a lot of those (I can post the full list if helpful) but it's not the case for all crates.
No amount of cargo clean
seems to be sufficient to fix this issue.
rust-analyzer version:
❯ rust-analyzer --version
rust-analyzer 2022-08-22
rustc version: (eg. output of rustc -V
)
❯ rustc -V
rustc 1.64.0-nightly (fe3342816 2022-08-01)
relevant settings:
(setq lsp-rust-analyzer-cargo-watch-command "clippy"
lsp-rust-analyzer-cargo-watch-args ["--target-dir" "/home/grfn/code/readyset/readyset/target/rust-analyzer"])
Does this only occur in rust-analyzer or also when manually running cargo check/clippy
?
Only in rust-analyzer
Tried this without the lsp-rust-analyzer-cargo-watch-args
, and the issue is still present. This is basically completely preventing me from using any recent version of rust-analyzer
Does this occur on any project for you or only a specific one? This is a really odd cargo error ... do you have any rust-analyzer configs set?
I started seeing the same error just today, and it's just like what @glittershark is describing; I initially assumed cleaning out my build directories would help but I'm just continuing to see the same errors. I'm running rust-analyzer 0.3.1170-standalone (b6d59f2bb 2022-08-14)
. I have no idea what triggered this, as it seemed to be working just fine yesterday, and I haven't made any changes to my config or anything...very odd.
In case it's helpful, here are the neovim settings I'm using for rust-analyzer:
["rust-analyzer"] = {
checkOnSave = {
command = "clippy",
extraArgs = {"--target-dir", "/tmp/rust-analyzer-clippy", "--", "-Aclippy::assertions_on_result_states", "-Aclippy::zero_prefixed_literal"},
},
}
Both of you have a target-dir set in your configs, does the issue disappear without that?
Interestingly the path shown in the error glittershark showed is not the same as the path set in their settings, so this looks like a cargo confusion, which may or may not be caused by our wrapper. Why this happens for you since recently only I have no idea though ...
So it would be good to check if the issue also appears if you disable the rustc-wrapper (I don't know the config name for this in neovim and the like)
Thanks for the quick reply, I disabled the target-dir setting but the same error still appeared. It took a couple of minutes to show up, but I'm guessing that might've just been because it had to rebuild things in the background for a while before it hit the error.
I also tried setting useRustcWrapper = false
and weirdly I get a completely different build error about an unresolved import:
failed to run build scripts
warning: unused import: `SelectStatement`
--> readyset-client/benches/rewrite.rs:2:48
|
2 | use nom_sql::{parse_select_statement, Dialect, SelectStatement};
| ^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: 1 warning emitted
error[E0432]: unresolved import `dataflow::node::bench`
--> readyset-server/benches/dataflow.rs:2:21
|
2 | use dataflow::node::bench::unique_misses;
| ^^^^^ could not find `bench` in `node`
As with the original errors though, these do not show up when I run cargo check
or cargo clippy
manually on the CLI.
Okay, so the plot thickens...after switching the settings back, the error is not happening anymore. And, indeed, I looked at one of the previous errors from the logs:
extern location for mysql_common does not exist: /Users/nmarino/readyset/public/target/debug/deps/libmysql_common-c6ccc495ac893f0a.rmeta
and while that file didn't used to exist, I checked again and it does exist now.
There is also a separate libmysql_common-7588457c393d498b.rmeta
that exists in the same directory that was already there previously. So it seems like there is something weird going on with the metadata hashes, maybe? I'm very much suggesting this off the cuff though, as I have virtually no knowledge or experience around how cargo actually works under the hood with respect to this stuff.
that bench
module issue is just a feature flag missing in our project, so not related to rust-analyzer