artifact-dir was not locked crash since nightly-2025-11-21

[stewartadam]

Problem

While checking my workspace, cargo crashes immediately:

thread 'main' (107096802) panicked at src/tools/cargo/src/cargo/core/compiler/build_runner/compilation_files.rs:467:18:
artifact-dir was not locked
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This is also causing rust-analyzer to crash on launch in VS Code.

cargo build and cargo run appear to be unaffected, as is cargo check (without --workspace).

Steps

$ cargo clean
$ VERSION=2025-11-20; rustup install nightly-$VERSION && rustup override set nightly-$VERSION
$ cargo check --workspace
   Compiling serde_derive v1.0.228
   Compiling bytemuck_derive v1.10.2
   Compiling thiserror-impl v2.0.17
   Compiling derive_more-impl v2.0.1
   Compiling variadics_please v1.1.
...

$ cargo clean
$ VERSION=2025-11-21; rustup install nightly-$VERSION && rustup override set nightly-$VERSION
$ cargo check --workspace

thread 'main' (107096802) panicked at src/tools/cargo/src/cargo/core/compiler/build_runner/compilation_files.rs:467:18:
artifact-dir was not locked
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Possible Solution(s)

Downgrade to nightly-2025-11-20 or earlier.

Notes

No response

Version

cargo 1.93.0-nightly (5c0343317 2025-11-18)
release: 1.93.0-nightly
commit-hash: 5c0343317ce45d2ec17ecf41eaa473a02d73e29c
commit-date: 2025-11-18
host: aarch64-apple-darwin
libgit2: 1.9.1 (sys:0.20.2 vendored)
libcurl: 8.7.1 (sys:0.4.83+curl-8.15.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 3.5.4 30 Sep 2025
os: Mac OS 26.1.0 [64-bit]

[stewartadam]

This might be related to my complex workspace setup, in which I am using the codegen-backend unstable feature for cranelift and have per-package overrides for it since not all my workspace packages are compatible with cranelift (due to rust-lang/rustc_codegen_cranelift#1588)

[epage]

CC @ranger-ross

[epage]

Do you have a public repo to run these reproduction steps on?

Can you re-run with backtraces enabled? The location of the panic is a fairly generic one

cargo/src/cargo/core/compiler/build_runner/compilation_files.rs

Line 467 in b0896a0

.expect("artifact-dir was not locked")

[ranger-ross]

Interesting, looking in the function where the panic is, a few lines above we return if the build is a check build

cargo/src/cargo/core/compiler/build_runner/compilation_files.rs

Lines 427 to 430 in b0896a0

	// Tests, check, doc, etc. should not be uplifted.
	if unit.mode != CompileMode::Build || file_type.flavor == FileFlavor::Rmeta {
	return None;
	}

So there is probably something about the workspace in question that calls uplift_to with CompileMode::Build even though cargo check was ran

[ranger-ross]

Also for the sake of completeness, this was caused by #16230

[epage]

It is checking the mode of the unit. Could this be an issue with build scripts or proc macros?

[epage]

I'm considering reverting #16230 in #16299 to not block people on nightly while this gets investigated.

[ranger-ross]

Sounds like a good idea to revert for now. I tried reproducing with a proc-macro and build scripts but neither caused an issue so I think the problematic scenario is a bit more complex. I'll see if I can reproduce this issue later this week

[epage]

Also @stewartadam if you can't provide reproduction steps, can you at least provide a run with CARGO_LOG=trace and redact any content you need to?