clean -p ignores build.target config when selecting target-specific artifacts

[karthikbhata97]

Problem

cargo clean -p <package> appears to ignore the configured build.target when selecting package artifacts to clean.

The cargo clean docs say that --target “may also be specified with the build.target config value”:

https://doc.rust-lang.org/cargo/commands/cargo-clean.html

However, when package selection is used, cargo clean -p behaves differently depending on whether the target is supplied through config or explicitly with --target.

Steps

On an aarch64-apple-darwin host:

cargo new --lib clean-repro
cd clean-repro

cargo build --config build.target='"aarch64-apple-darwin"'

cargo clean -p clean-repro --dry-run -v --config build.target='"aarch64-apple-darwin"'
cargo clean -p clean-repro --dry-run -v --target aarch64-apple-darwin

Actual Behavior

The build creates artifacts under the target-specific directory:

target/aarch64-apple-darwin/debug/...

But cleaning with build.target reports no package artifacts:

  $ cargo clean -p clean-repro --dry-run -v --config build.target='"aarch64-apple-darwin"'
       Summary 0 files
  warning: no files deleted due to --dry-run

Cleaning with explicit --target finds the package artifacts:

  $ cargo clean -p clean-repro --dry-run -v --target aarch64-apple-darwin
  .../target/aarch64-apple-darwin/debug/.fingerprint/clean-repro-.../lib-clean_repro
  .../target/aarch64-apple-darwin/debug/incremental/clean_repro-...
       Summary 18 files, 53.1KiB total
  warning: no files deleted due to --dry-run

Expected Behavior

These two commands should select the same target-specific artifacts:

  cargo clean -p clean-repro --dry-run -v --config build.target='"aarch64-apple-darwin"'
  cargo clean -p clean-repro --dry-run -v --target aarch64-apple-darwin

This would match the documentation saying --target may also be specified with build.target.

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.95.0 (f2d3ce0bd 2026-03-21)
release: 1.95.0
commit-hash: f2d3ce0bd7f24a49f8f72d9000448f8838c4e850
commit-date: 2026-03-21
host: aarch64-apple-darwin
libgit2: 1.9.2 (sys:0.20.4 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.3.1 [64-bit]

[0xPoe]

I can reproduce this issue, and I believe the bug originates from here:

cargo/src/cargo/ops/cargo_clean.rs

Lines 203 to 211 in e8fbc38

	.collect::<CargoResult<_>>()?;
	// A Vec of layouts. This is a little convoluted because there can only be
	// one host_layout.
	let layouts = if targets.is_empty() {
	vec![(CompileKind::Host, &host_layout)]
	} else {
	target_layouts
	.iter()
	.map(|(kind, layout)| (*kind, layout))

That checks only the raw CLI --target list, not the resolved target kinds.
So when the target comes from build.target, Cargo falls back to the host layout and scans target/debug/... instead of target/aarch64-apple-darwin/debug/... for package artifacts.

[0xPoe]

I will work on a fix for it.