In some conditions, r-a calls cargo metadata in such a way that it attempts to update rust-src's lockfile for core

[lf-]

For some reason, I started having rust-analyzer calling Cargo in such a way that Cargo is attempting to recreate the lock file of core, which is very much not something that should happen. I actually think rust-analyzer should probably pass --frozen for such an invocation, since it does not currently, and such a command could actually succeed in messing up the global rust sources if they weren't on a read-only filesystem such as /nix/store.

This means that I get load errors. It seems to be that the lockfile is attempted to be updated because of some rand dependency of core?

You can get the broken project version from here. I am using Nix for everything including r-a on this project, since it's a rust/C++ plugin. https://github.com/lf-/nix-otel/tree/41fba6dccbca74fdee3a1c6a8e88c9b49b4c50d4

r-a provided by Nix is invoked from within the nix develop shell using a shim that calls direnv exec.

To reproduce the broken Cargo command, run this from any computer with Nix:

========== The one r-a ran ==================
$ nix develop 'github:lf-/nix-otel?rev=41fba6dccbca74fdee3a1c6a8e88c9b49b4c50d4' -c sh -c '"cargo" "metadata" "--format-version" "1" "--manifest-path" "$RUST_SRC_PATH/core/Cargo.toml" "--filter-platform" "x86_64-unknown-linux-gnu"'
    Updating crates.io index
error: failed to write /nix/store/m20v9v9h0d1xmq6wc4x27alh8snba76j-rust-lib-src/core/Cargo.lock

Caused by:
  failed to open: /nix/store/m20v9v9h0d1xmq6wc4x27alh8snba76j-rust-lib-src/core/Cargo.lock

Caused by:
  Permission denied (os error 13)

======== The one explaining why Cargo even tried that ============
$ nix develop 'github:lf-/nix-otel?rev=41fba6dccbca74fdee3a1c6a8e88c9b49b4c50d4' -c sh -c '"cargo" "metadata" "--format-version" "1" "--manifest-path" "$RUST_SRC_PATH/core/Cargo.toml" "--filter-platform" "x86_64-unknown-linux-gnu" --frozen'
error: failed to get `rand` as a dependency of package `core v0.0.0 (/nix/store/m20v9v9h0d1xmq6wc4x27alh8snba76j-rust-lib-src/core)`

Caused by:
  failed to load source for dependency `rand`

Caused by:
  Unable to update registry `crates-io`

Caused by:
  attempting to make an HTTP request, but --frozen was specified

rust-analyzer version: 2022-10-03

rustc version: 1.63.0, from nix

relevant settings: (eg. client settings, or environment variables like CARGO, RUSTUP_HOME or CARGO_HOME)

nix-otel/plugin - [main] » echo $RUST_SRC_PATH 
/nix/store/m20v9v9h0d1xmq6wc4x27alh8snba76j-rust-lib-src

RA_LOG for the log below:

    "rust-analyzer.server.extraEnv": {
        "RA_LOG": "info,salsa::derived::slot=warn,chalk_recursive=warn,hir_ty::traits=warn,flycheck=trace,rust_analyzer::main_loop=warn,ide_db::apply_change=warn,project_model=debug,proc_macro_api=debug,hir_expand::db=error,ide_assists=debug,ide=debug"
    },

Extensive rust-analyzer log:

https://gist.github.com/lf-/32dd8e796e2b9d6fe91ba0c9a7879398

[bjorn3]

This is two separate issues on rust's end.

• The Cargo.lock file shipped with the rust-src component is a literal copy of the Cargo.lock in the rust repo and as such contains not just the standard library, but also the compiler and most tools. As such when using this file in the rust-src component, cargo will attempt to update it by removing all references to non-existent and unused crates. This fails if it is readonly.
• It doesn't even use this Cargo.lock file as the Cargo.toml file next to it specifying all workspace members is missing. As such it will look for library/core/Cargo.lock when getting the metadata for libcore and create it from scratch if it doesn't exist. Just copying the workspace Cargo.toml file won't work as it references the compile and most tools. If those are missing, it will just error out.

[lf-]

Ugh. That's pretty ugly.

I wonder if rust-analyzer could somehow special case core since presumably the cargo metadata is known?

[lf-]

I believe that this is upstream issue rust-lang/rust#95736

[Veykril]

This somewhat related to #7637 I guess, where we'd like to have library be a separate workspace (from r-a's point of view at least)

[RalfJung]

rust-lang/cargo#10096 is also related.

[Veykril]

I'll close this, I am pretty sure the cause for OP's problem was their editor telling r-a that the sysroot was a loaded lsp workspace causing us to attempt to run cargo metadata on it