fix rustc_private analysis on read-only / symlinked toolchains

[onlycs]

Problem

With a nix toolchain, every macro-generated TyCtxt query getter (tcx.mir_keys(()), e.g.) resolves to {unknown}. Three independent bugs cause this.

1. the rustc-src lockfile is never found

The rustc-dev component ships compiler sources as [rustc-src]/rust/compiler/rustc/Cargo.toml, with no workspace root manifest. The lockfile lives two levels up at [rustc-src]/rust/Cargo.lock. FetchMetadata::new only looks for a lockfile directly next to the manifest, so the rustc metadata fetch runs --locked with no lockfile available. In a read-only store, cargo cannot create one and errors:

error: cannot create the lock file /nix/store/…/rustc-src/rust/compiler/rustc/Cargo.lock
because --locked was passed to prevent this

FetchMetadata::exec then silently falls back to the --no-deps pre-fetch, whose metadata contains only the rustc-main stub package. rustc_middle, rustc_hir, etc. never enter the crate graph.

Instead, we walk up the manifest's ancestor directories to find the lockfile, then reuse the existing lockfile-copy mechanism.

2. the lockfile-copy mechanism never worked

Even with the lockfile found, make_lockfile_copy always returned None:

• NamedTempFile::new opens with only create_new(true). This is incorrect. Creating or truncating a file requires write or append access, so creation failed unconditionally, on every platform. This also affects the Windows proc-macro dylib copies.

• On Linux the temp file is unlinked and re-addressed as /proc/self/fd/N. That path only is only valid to rust-analyzer: in the spawned cargo, /proc/self refers to cargo's fd table, and the descriptor isn't inherited across exec (O_CLOEXEC). So the lockfile-copy path handed to cargo metadata was a dangling name from cargo's pov.

• cargo additionally rejects lockfile paths not literally named Cargo.lock, which the {prefix}{pid}-{counter} naming scheme violates.

Now, new_from_existing copies into a temporary directory, preserves the original file name, and makes the copy writable.

3: symlinked proc-macro dylibs are skipped

WorkspaceBuildScripts::rustc_crates scans the target libdir for the prebuilt proc-macro dylibs (librustc_macros.so & co.) using DirEntry::file_type(), which does not follow symlinks. Nix sysroots symlink every file into place, so all dylibs were filtered out. Without rustc_macros, rustc_queries! never expands, the generated rustc_with_all_queries macro doesn't exist, and none of define_callbacks!'s output (those macro-generated query getters) is ever created.

The fix here was to just use fs::metadata which traverses symlinks.

AI disclosure

These changes were authored with AI assistance (Claude Code); the commits carry Co-Authored-By trailers. I have reviewed the changes, use them in a current project using a patched build, and can answer questions about them myself.