`cargo check` builds a dependency shared by a proc macro and library twice

[Alexendoo]

Problem

If you have a library and a proc macro that depend on the same package it will be built twice when cargo checking

Steps

mkdir -p {.,b,proc}/src
touch {.,b,proc}/src/lib.rs

cat > Cargo.toml << END
[package]
name = "a"
version = "0.1.0"
edition = "2024"

[dependencies]
b = { path = "b" }
proc = { path = "proc" }
END

cat > b/Cargo.toml << END
[package]
name = "b"
version = "0.1.0"
edition = "2024"
END

cat > proc/Cargo.toml << END
[package]
name = "proc"
version = "0.1.0"
edition = "2024"

[lib]
proc-macro = true

[dependencies]
b = { path = "../b" }
END

cargo +nightly check -v

Produces

     Locking 2 packages to latest Rust 1.88.0-nightly compatible versions
   Compiling b v0.1.0 (/home/gh-Alexendoo/temp/b)
     Running `/home/gh-Alexendoo/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/bin/rustc --crate-name b --edition=2024 b/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=209 --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values())' -C metadata=8a8269058e2bd7b4 -C extra-filename=-05ea99ee22fc8eaa --out-dir /home/gh-Alexendoo/temp/target/debug/deps -C incremental=/home/gh-Alexendoo/temp/target/debug/incremental -L dependency=/home/gh-Alexendoo/temp/target/debug/deps`
     Running `/home/gh-Alexendoo/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/bin/rustc --crate-name b --edition=2024 b/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=209 --crate-type lib --emit=dep-info,metadata -C embed-bitcode=no -C debuginfo=2 --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values())' -C metadata=b6ec3bcaacc23d79 -C extra-filename=-c7713095b182e137 --out-dir /home/gh-Alexendoo/temp/target/debug/deps -C incremental=/home/gh-Alexendoo/temp/target/debug/incremental -L dependency=/home/gh-Alexendoo/temp/target/debug/deps`
   Compiling proc v0.1.0 (/home/gh-Alexendoo/temp/proc)
     Running `/home/gh-Alexendoo/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/bin/rustc --crate-name proc --edition=2024 proc/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=209 --crate-type proc-macro --emit=dep-info,link -C prefer-dynamic -C embed-bitcode=no --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values())' -C metadata=576444831ff6b2bc -C extra-filename=-6aee3d4e991d2801 --out-dir /home/gh-Alexendoo/temp/target/debug/deps -C incremental=/home/gh-Alexendoo/temp/target/debug/incremental -L dependency=/home/gh-Alexendoo/temp/target/debug/deps --extern b=/home/gh-Alexendoo/temp/target/debug/deps/libb-05ea99ee22fc8eaa.rlib --extern proc_macro`
    Checking a v0.1.0 (/home/gh-Alexendoo/temp)
     Running `/home/gh-Alexendoo/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/bin/rustc --crate-name a --edition=2024 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=209 --crate-type lib --emit=dep-info,metadata -C embed-bitcode=no -C debuginfo=2 --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values())' -C metadata=08291f8ea2cb2022 -C extra-filename=-c68a1279c4f9496f --out-dir /home/gh-Alexendoo/temp/target/debug/deps -C incremental=/home/gh-Alexendoo/temp/target/debug/incremental -L dependency=/home/gh-Alexendoo/temp/target/debug/deps --extern b=/home/gh-Alexendoo/temp/target/debug/deps/libb-c7713095b182e137.rmeta --extern proc=/home/gh-Alexendoo/temp/target/debug/deps/libproc-6aee3d4e991d2801.so`
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.24s

Possible Solution(s)

No response

Notes

The first is has --emit=dep-info,metadata -C debuginfo=2 and the second --emit=dep-info,metadata,link, but using --config profile.dev.debug=false doesn't unify them

I wasn't sure if this was #3501 or not, but it seems related

Version

cargo 1.88.0-nightly (0e93c5bf6 2025-04-05)

[epage]

I believe one invocation is to generate the metadata needed for a on the target while the other is doing a full build so proc can be run on the host.

This is similar to #3501 in that one build of b is like cargo check and the other build is like cargo build. The difference with #3501 is that that issue is mainly caring about cargo check && cargo build which is focused on how we organize the cache while this would require us to change how we build the unit graph to consolidate the metadata generation. These type of host/target consolidations are tricky which the time to get it right and the accompanying maintenance burden might out weigh the build time benefits.

[joshtriplett]

The operations done by check and build currently use incompatible metadata, so we can't currently reuse one in the other. That means we don't have a way to avoid the duplication here. If that ever changes in the compiler, we could then potentially consider deduplicating here.