-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
fix: -Cmetadata includes whether extra rustflags is same as host #14432
Conversation
c877f48
to
0776730
Compare
See rust-lang/cargo 14253
0776730
to
1b68942
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm (up to nit) 👍
let target_configs_are_different = unit.rustflags != host_info.rustflags | ||
|| unit.rustdocflags != host_info.rustdocflags | ||
|| bcx | ||
.target_data | ||
.target_config(CompileKind::Host) | ||
.links_overrides | ||
!= unit.links_overrides; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels a bit brittle. If we don't remember to update this with anything else that is different but not in metadata already, we'll see this problem again.
The only thoughts I had are
- Putting this question in the unit or host info to answer
- Hashing
unit.kind.is_host() && !bcx.gctx.target_applies_to_host().unwrap_or_default()
Note: answering this is more important for long term reliability and stabilization. This doesn't need to block fixing people who are using the unstable feature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to r= me when ready
`-Ztarget-applies-to-host --config target-applies-to-host=false` make it possible to build two units for the same output directory with different rustflags (one with artifact/target rustflags, one with none/host rust flags). Those flags aren't included in the `-Cmetadata` hash which is used to disambiguate different versions of crates, resulting in a conflict. The actual error being produced appears to be the result of two invocations of `rustc` racing and clobbering each other. While we don't hash RUSTFLAGS because it may contain absolute paths that hurts reproducibility, we track whether a unit's RUSTFLAGS is from host config, so that we can generate a different metadata hash for runtime and compile-time units.
1b68942
to
d12c716
Compare
Removed the comment and added a note above the hack. Thanks people. Going to merge this. @bors r=epage |
☀️ Test successful - checks-actions |
Update cargo 12 commits in ba8b39413c74d08494f94a7542fe79aa636e1661..8f40fc59fb0c8df91c97405785197f3c630304ea 2024-08-16 22:48:57 +0000 to 2024-08-21 22:37:06 +0000 - Tests rely on absence of RUST_BACKTRACE (rust-lang/cargo#14441) - fix: -Cmetadata includes whether extra rustflags is same as host (rust-lang/cargo#14432) - [mdman] Normalize newlines when rendering options (rust-lang/cargo#14428) - fix: doctest respects Cargo's color options (rust-lang/cargo#14425) - Be more permissive while packaging unpublishable crates. (rust-lang/cargo#14408) - fix: Limiting pre-release match semantics to use only on `OptVersionReq::Req` (rust-lang/cargo#14412) - test: add a regression test for Issue 14409 (rust-lang/cargo#14430) - chore: update label trigger for Command-info (rust-lang/cargo#14422) - doc: add lockfile-path unstable doc section (rust-lang/cargo#14423) - doc: update lockfile-path tracking issue (rust-lang/cargo#14424) - fix: remove list owners feature of info subcommand (rust-lang/cargo#14418) - Lockfile path tests (follow-up) (rust-lang/cargo#14417)
What does this PR try to resolve?
Fixes #14253
The root cause is described in #14253 (comment):
While we don't hash RUSTFLAGS because it may contain absolute paths that
hurts reproducibility, we track whether a unit's RUSTFLAGS is from host
config, so that we can generate a different metadata hash for runtime
and compile-time units.
How should we test and review this PR?
This hack is only enabled when
target-applies-to-host=false
and when compile kind is the host platform, so the shouldn't affect any stable behavior.Additional information
cc @gmorenz
I found time working on this PR before my travel. Feel free to cherry pick and create a new PR if this is not correct.