-Zno-link is broken (take 2)

[bjorn3]

I tried this code:

echo "pub fn hello() {}" > dep.rs
echo "extern crate dep; fn main() { dep::hello() }" > main.rs
rustc +nightly --crate-name dep dep.rs --crate-type lib --emit=metadata,link
rustc +nightly --crate-name foo main.rs --crate-type bin --extern dep=libdep.rmeta -Zno-link

I expected to see this happen: It compiles, but doesn't link anything.

Instead, this happened:

error: crate `dep` required to be available in rlib format, but was not found in this form

error: aborting due to 1 previous error

Meta

Reported by @weihanglo at https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/How.20to.20use.20.60-Zno-link.60.2F.60-Zlink-only.60.20correctly/with/520969639

Previous breakage: #77857

rustc --version --verbose:

rustc 1.89.0-nightly (45f256d9d 2025-05-27)
binary: rustc
commit-hash: 45f256d9d7cffb66185c0bf1b8a864cba79db90c
commit-date: 2025-05-27
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.5

[bjorn3]

This is more tricky to fix than I expected. We need to delay the dependency_formats call to link time. Currently it is used at the following locations:

• Encoding it in the crate metadata for dylibs. Implementing Remove dependency formats from crate metadata #96708 would allow fixing this.
• Figuring out which crates should participate in LTO. This is not that much of an issue as LTO needs bitcode for all dependencies to be available anyway.
• In allocator_kind_for_codegen to figure out if the allocator shim is necessary. Hopefully we will be able to get rid of the allocator shim at some point.

[weihanglo]

Hey @bjorn3. What is the current status of this, I guess it is tracked in rust-lang/compiler-team#908?

We may have some bandwidth to help this move forwards, so we then can push the Cargo integration of it :)

[bjorn3]

Yeah, I've been tracking the necessary refactorings on that MCP issue. I'm currently at the point where it would in principle be possible to move the LTO step to link_binary. I currently need to figure out how to best adapt the CodegenBackend trait to allow passing MaybeLtoModules<M> from join_codegen to link despite it being a generic type while CodegenBackend has to be dyn compatible and at the same time ensuring that (de)serialization of it works. (I already implemented the actual (de)serialization on a branch: main...bjorn3:rust:lto_refactors15) Maybe I will have to use Box<dyn Any> + a pair of extra methods on CodegenBackend for (de)serialization, but that is a bit ugly. Once the LTO step is moved, it shouldn't be too hard to get rid of the dependency_formats dependency before linking, which should be enough to fix -Zno-link.