Recompilation regression on cdylib on toolchain mixing

[mayeul-zama]

Problem

Hi,

On a library crate

Cargo.toml

[package]
name = "crate_name"
version = "0.1.0"
edition = "2021"
[lib]
crate-type = ["lib", "cdylib"]

lib.rs

/// ```rust
/// crate_name::a();
/// ```
pub fn a() {}

Makefile

stable:
	cargo +1.84.1 test
nightly:
	cargo +nightly-2024-12-15 test
broken:
	cargo clean
	make stable
	make nightly
	make stable

make broken fails on the 2nd call of the stable test doctest compilation with error[E0514]: found crate `crate_name` compiled by an incompatible version of rustc
Using +nightly-2024-12-14 instead of +nightly-2024-12-15 fixes the issue (cargo diff 20a4432...769f622)
As of nightly-2025-02-19, this error still appears.
Does not fail with either crate-type = ["lib"] or crate-type = ["cdylib"]

This looks like a cargo regression on compilation artifacts reuse.

I'm not sure what guarantees cargo make when mixing toolchains without cleaning.

When also using rlib, there is also error (didn't first appear with nightly-2024-12-15, already present in nightly-2024-12-14):

thread 'main' panicked at src/cargo/core/compiler/fingerprint/mod.rs:1160:13:
assertion failed: mtimes.insert(output.clone(), mtime).is_none()

With crate-type = ["lib", "rlib"], make broken fails on the 2nd call of the stable test compilation
With crate-type = ["lib", "cdylib", "rlib"], make broken fails on the 1st call of the nightly test compilation
With crate-type = ["cdylib", "rlib"], we get the error[E0514] seen before
With crate-type = ["rlib"], no fail

I can open a separate issue if needed for this different error

Steps

No response

Possible Solution(s)

Running cargo clean between compilation when changing toolchain

Notes

No response

Version

$ cargo +nightly-2024-12-15 --version
cargo 1.85.0-nightly (769f622e1 2024-12-14)

And later versions

[weihanglo]

Haven't chased down the root cause yet, but here might be the bad cargo submodule update PR: rust-lang/rust#134278.

[ehuss]

This seems to be caused by #14917.

Before #14917, stable and nightly would use the same hash for the fingerprint file for building the library. When switching between toolchains, it's able to detect that the rustc version has changed.

After, it is now storing the fingerprint separately. The last cargo +stable test line loads its fingerprint, and everything looks ok, so it doesn't rebuild the library, and fails.

Offhand I'm not sure how to fix that.

[mayeul-zama]

Thanks for the investigation!

Updating the stable version to 1.85 fixes the first issue
I guess it's because it also includes #14917

Maybe leaving this incompatibility between nightly and some "old" (not latest) stable toolchains is acceptable (as it will "disappear" as people update their stable toolchains and can already be avoided by using the latest stable).
To be noted, this incompatibility can break things without triggering E0514 (it happened to me) which is unfortunate.

There's still an issue with rlib

[weihanglo]

After, it is now storing the fingerprint separately. The last cargo +stable test line loads its fingerprint, and everything looks ok, so it doesn't rebuild the library, and fails.

-Zchecksum-freshness might help?