Show more details on "Dirty ...: dependency info changed"

[RalfJung]

Problem

Debugging unexpected rebuilds got a lot nicer with cargo build -v showing a reason for "Dirty" crates. However, sometimes one gets

       Dirty miri v0.1.0 (D:\a\miri\miri): dependency info changed

which is not really actionable, given that nothing about the crate itself (Cargo.toml / Cargo.lock) changed.

Proposed Solution

Would be great to get some more details about what changed here. For this specific case, the cargo::core::compiler::fingerprint log shows

2024-05-04T06:41:27.4318113Z    0.102008300s  INFO prepare_target{force=false package_id=miri v0.1.0 (D:\a\miri\miri) target="miri"}: cargo::core::compiler::fingerprint: fingerprint dirty for miri v0.1.0 (D:\a\miri\miri)/Build/TargetInner { name: "miri", tested: false, doc: true, ..: with_path("D:\\a\\miri\\miri\\src\\bin\\miri.rs", Edition2021) }
2024-05-04T06:41:27.4320415Z    0.102041200s  INFO prepare_target{force=false package_id=miri v0.1.0 (D:\a\miri\miri) target="miri"}: cargo::core::compiler::fingerprint:     dirty: UnitDependencyInfoChanged { old_name: "ctrlc", old_fingerprint: 6202229392602597251, new_name: "ctrlc", new_fingerprint: 4374262352119191711 }

So apparently the ctrlc crate changed somehow. I don't know what this means, but maybe it would make sense to mention ctrlc in the cargo build -v output. Maybe it could even explain what changed about ctrlc -- I have no idea what flows into this fingerprint that apparently changed.

Notes

No response

[epage]

When we added the messages in #11407, we acknowledged that we could extend this with more information. For me, part of the challenge is how much is reasonable to show with -v or -vv. Each person enabling those flags is likely wanting something different. If its just showing which deps changed, then that is likely reasonable.

When we finish #2904, the expectation is we'd have a cargo report subcommand that could go into more detail after the fact. This provides a more specialized view that allows us to go into more detail and helps when these aren't reproducible (or the way to reproduce is not yet known).

[weihanglo]

There was a change (e08848c) in #11407 giving richer information. It was backed out because the new display requires more design discussions than others.

I don't mind adding them back behind -vv, though I agree with epage that #2904 might be a better way out.

[Timmmm]

This seems to work as a temporary measure:

CARGO_LOG=cargo::core::compiler::fingerprint=info cargo build

[weihanglo]

FWIW, in -Zbuild-analysis #15844 there is a structured logging mechanism that has a plan for showing rebuild reasons.

[ajaysathvik]

can i work on this

[weihanglo]

@ajaysathvik our focus is currently on #15844 the structured logging. I personally don't think this will go anywhere in short-term. I'll propose to the team taht we close this

@rustbot label -S-accepted +S-propose-close