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
I would like to report another sighting of this issue. Rust-analyzer seemed to work just fine 2-3 weeks back when I had tried it last, but I have started seeing this error quite recently. (MacOS Ventura, Running: Rust-analyze through VSCode.)
% ~/.vscode/extensions/rust-lang.rust-analyzer-0.3.1386-darwin-arm64/server/rust-analyzer --version rust-analyzer 0.3.1386-standalone (f1b257f4e 2023-01-27)
There is a very long list of errors I see in the VsCode output terminal. I'm pasting a small excerpt. The errors wrt mysql is a common thread across all sightings it appears.
[ERROR project_model::workspace] cyclic deps: readyset_mysql(CrateId(408)) -> readyset_client_test_helpers(CrateId(395)), alternative path: readyset_client_test_helpers(CrateId(395)) -> readyset_mysql(CrateId(408)) [ERROR project_model::workspace] cyclic deps: readyset_psql(CrateId(413)) -> readyset_client_test_helpers(CrateId(395)), alternative path: readyset_client_test_helpers(CrateId(395)) -> readyset_psql(CrateId(413)) [ERROR project_model::workspace] cyclic deps: replicators(CrateId(439)) -> readyset_server(CrateId(419)), alternative path: readyset_server(CrateId(419)) -> replicators(CrateId(439)) [ERROR rust_analyzer::lsp_utils] failed to run build scripts: error: extern location for mysql_common does not exist: /Users/gautam/code/readyset/crates/target/debug/deps/libmysql_common-f05a636575d6cedd.rmeta --> /Users/gautam/.cargo/registry/src/github.com-1ecc6299db9ec823/mysql-22.2.0/src/lib.rs:856:5 | 856 | use mysql_common as myc; | ^^^^^^^^^^^^
I am fairly certain this is caused by our rustc wrapper, setting "rust-analyzer.cargo.buildScripts.useRustcWrapper": false, might fix it (at the cost of r-a reporting build scripts errors when the workspace doesn't compile on start up).
So to fix this, all you have to do is:
- Clean project
- Sync project (this is the part where you get the error)
- Ignore the error and build the project
- Lastly sync the project again
- Now all is good. Happy coding :)
2. Sync project
What does this mean?
I am fairly certain this is caused by our rustc wrapper, setting
"rust-analyzer.cargo.buildScripts.useRustcWrapper": false,might fix it (at the cost of r-a reporting build scripts errors when the workspace doesn't compile on start up).
This seems to fix it for me
Closing this as its most likely an issue with the wrapper which we can't do anything about.