`cargo test` fails to build when downstream crate declares `crate-type = ["rlib", "dylib"]`

[Firestar99]

Problem

The minimal repro project https://github.com/Firestar99/cargo_dylib_dev_dep_fail can be cargo build normally, but building tests with cargo test --no-run fails:

   Compiling liba v0.1.0 (/home/firestar99/workspace/bla/cargo_dylib_dev_dep_fail/liba)
   Compiling libb v0.1.0 (/home/firestar99/workspace/bla/cargo_dylib_dev_dep_fail/libb)
   Compiling libc v0.1.0 (/home/firestar99/workspace/bla/cargo_dylib_dev_dep_fail/libc)
error: cannot satisfy dependencies so `std` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

[... Repeat the error above for the dependencies core, alloc, compiler_builtins, libc, rustc_std_workspace_core, unwind, cfg_if, miniz_oxide, adler2, hashbrown, rustc_std_workspace_alloc, std_detect, rustc_demangle, addr2line, gimli, object, memchr and panic_unwind]

error: could not compile `libb` (lib test) due to 19 previous errors
warning: build failed, waiting for other jobs to finish...

The workspace consists out of these crates:

• liba
  • lib with crate-type = ["rlib", "dylib"]
  • exports SymbolLibA
• libb
  • a proc-macro crate declaring a trivial proc macro
  • dev-dependency on libc
    • uses SymbolLibC from libc in tests and doctests
• libc
  • standard lib
  • depends on liba and libb
  • exports SymbolLibC, which uses SymbolLibA internally

For some reason, the combination of liba having the additional crate-type dylib (next to lib) and the proc-macro crate libb having a dev-dependency on libc causes cargo test to fail building. I'd be fine with liba being imported as a lib crate-type on the CPU, I only need liba to have the option of being dylib for the rust-gpu custom codegen backend.

Steps

git clone https://github.com/Firestar99/cargo_dylib_dev_dep_fail
cd cargo_dylib_dev_dep_fail
cargo test --no-run

observe failure

Possible Solution(s)

No response

Notes

This is a minimized version of #15890

• both cargo b and cargo b --profile test work, it seems that cargo test --no-run passes something extra that causes it to fail
• crate-type lib and rlib seem to be interchangeable
• crates seem to be lazy-imported, so libb must use a symbol from libc it must use a symbol from liba

Version

cargo 1.89.0 (c24e10642 2025-06-23)

[nazar-pc]

Sounds similar to what I described in #12260 (comment) (and that issue more general) and likely related to #1982 as well

Support for multiple library types right now is very basic.