Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
RalfJung opened this issue May 4, 2024 · 2 comments · May be fixed by #13883
Open

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

RalfJung opened this issue May 4, 2024 · 2 comments · May be fixed by #13883
Labels
A-rebuild-detection Area: rebuild detection and fingerprinting C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review

Comments

@RalfJung
Copy link
Member

RalfJung commented May 4, 2024

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

@RalfJung RalfJung added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels May 4, 2024
@epage epage added the A-rebuild-detection Area: rebuild detection and fingerprinting label May 4, 2024
@epage
Copy link
Contributor

epage commented May 4, 2024

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).

@epage epage added S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review and removed S-triage Status: This issue is waiting on initial triage. labels May 4, 2024
@torhovland torhovland linked a pull request May 8, 2024 that will close this issue
@weihanglo
Copy link
Member

weihanglo commented May 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rebuild-detection Area: rebuild detection and fingerprinting C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants