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

Remove requirement for --target when invoking Cargo with -Zbuild-std #14317

Merged
merged 4 commits into from
Oct 30, 2024

Conversation

harmou01
Copy link
Contributor

This PR addresses this issue re: build-std stabilization. We believe the requirement for --target to be specified when invoking cargo with -Zbuild-std, from our testing, is no longer needed. Now, with this change, by default Cargo will use the Host CompileKind, rather than a manually specified CompileTarget. We propose removing this restriction in order to test this more widely. Our own testing is detailed below.

This change has been tested in the following manner:

  • Building crates depending on proc_macro, std, and build scripts (which themselves depend on proc_macro)
  • Various RUSTFLAGS, such as -Zsanitizer=cfi, -Cembed-bitcode=yes, -Cforce-frame-pointers, -Cforce-unwind-tables=yes, -Csoft-float=yes, -Zbranch-protection=pac-ret.

@rustbot
Copy link
Collaborator

rustbot commented Jul 29, 2024

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 29, 2024
@@ -97,11 +97,6 @@ impl BuildConfig {
},
};

if gctx.cli_unstable().build_std.is_some() && requested_kinds[0].is_host() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add some build-std tests for relying on host target?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might not be easy to set up though. Maybe we can only do this on certain platforms like x86_64 linux.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ehuss I meant this but now it seems to be a separate issue so you're right.

// Fixing rust-lang/rust#117839.
// on macOS it never gets remapped.
// Might be a separate issue, so only run on Linux.
#[cargo_test(build_std_real)]
#[cfg(target_os = "linux")]
fn remap_path_scope() {

@ehuss
Copy link
Contributor

ehuss commented Jul 29, 2024

Yea, I'd like to see some tests added. There is a dedicated build-std suite that would be appropriate for this. Testing proc-macros is the most important part, and including shared dependencies I think will also be important.

Also, the documentation will need updating, too.

I'm not sure what @weihanglo means by only working on certain platforms. This should work on all host platforms that we test with.

One key difference of how cargo works today versus when this was written is that cargo now defaults to "cross compile mode", and then has a separate pass which unifies things when building in "host only" mode. Because the host dependencies will not be wired up to the std dependencies, that means they essentially get forked and built twice. Overall that seems like it should work, though I'm still uncertain about RUSTFLAGS compatibility.

This may complicate rust-lang/wg-cargo-std-aware#31, since cargo would need to be careful about how it disables the sysroot. But overall I think it should be workable.

@harmou01
Copy link
Contributor Author

harmou01 commented Aug 1, 2024

Thanks @ehuss. Could you clarify what you mean relating to the disable sysroot issue?

@ehuss
Copy link
Contributor

ehuss commented Aug 10, 2024

rust-lang/wg-cargo-std-aware#31 is recommending to add a flag to rustc to disable sysroot lookups. Cargo would pass that flag when using build-std to ensure that rustc does not ever attempt to load crates from the sysroot (to avoid various weird errors). With the change in this PR, proc-macros and build scripts will start using the standard library from the sysroot.

We will need some way to tell cargo to not pass that flag for host crates. That may be complicated due to the way rebuild_unit_graph_shared works, since it might lose the information about whether or not something is for "host" or not. I have not looked at if that is a problem or not, or how complicated that will be to support.

That seems like something we can deal with in the future, though.

@adamgemmell
Copy link

With the change in this PR, proc-macros and build scripts will start using the standard library from the sysroot.

I think this is already the case. It looks like cargo assumes, for the purpose of build dependencies, that artifact deps can execute on the host when a --target isn't provided but assumes they can't even if --target=[host]. It therefore makes sense that when in --target mode build scripts would need to use the sysroot.

Even though they technically can, I don't think build scripts using --extern std in host mode is even any better since right now building and running build scripts doesn't depend on building std. I think this would just slow down builds.

There is no longer a need for the --target to be specified in every case
when using -Zbuild-std. Cargo will default to the Host CompileKind when
no --target is specified.
@harmou01 harmou01 force-pushed the dev/harmou01/remove-target-flag-req branch from c3edeff to 388bceb Compare September 24, 2024 17:01
@rustbot rustbot added the A-documenting-cargo-itself Area: Cargo's documentation label Sep 24, 2024
Add a new test case for building a crate with -Zbuild-std, without the
requirement for the --target flag, and that uses a proc_macro.
Add a test case which ensures that -Zbuild-std without --target
correctly handles building a crate that has a shared dependency between
it's own build script, and std.
@harmou01 harmou01 force-pushed the dev/harmou01/remove-target-flag-req branch from 388bceb to 5a66672 Compare September 25, 2024 12:23
@harmou01
Copy link
Contributor Author

harmou01 commented Oct 21, 2024

@ehuss & @weihanglo , have you had a chance to look at the updated changes? Thanks!

@ehuss
Copy link
Contributor

ehuss commented Oct 30, 2024

Thanks, sorry for the delay!

I'm not fully confident this won't unearth some issues since there are a lot of subtle interactions (like the RUSTFLAGS thing I mentioned above). However, I can't think of anything specific that will be a problem. Really appreciate you helping with this!

@bors r+

@bors
Copy link
Collaborator

bors commented Oct 30, 2024

📌 Commit 5a66672 has been approved by ehuss

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 30, 2024
@bors
Copy link
Collaborator

bors commented Oct 30, 2024

⌛ Testing commit 5a66672 with merge 9abcaef...

@bors
Copy link
Collaborator

bors commented Oct 30, 2024

☀️ Test successful - checks-actions
Approved by: ehuss
Pushing 9abcaef to master...

@bors bors merged commit 9abcaef into rust-lang:master Oct 30, 2024
24 checks passed
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 2, 2024
Update cargo

18 commits in e75214ea4936d2f2c909a71a1237042cc0e14b07..0310497822a7a673a330a5dd068b7aaa579a265e
2024-10-25 16:34:32 +0000 to 2024-11-01 19:27:56 +0000
- Add more metadata to `rustc_fingerprint` (rust-lang/cargo#14761)
- test(rustfix): switch to a simpler case for dedup-suggestions (rust-lang/cargo#14765)
- chore(deps): update rust crate security-framework to v3 (rust-lang/cargo#14766)
- chore(deps): update rust crate gix to 0.67.0 (rust-lang/cargo#14762)
- fix(util): Respect all `..`s in `normalize_path` (rust-lang/cargo#14750)
- test(doc): Resolve flaky test (rust-lang/cargo#14760)
- refactor(test): Remove dead 'expect_stdout_contains_n' check (rust-lang/cargo#14759)
- add unstable -Zroot-dir flag to configure the path from which rustc should be invoked (rust-lang/cargo#14752)
- docs(resolver): Further v3 prep (rust-lang/cargo#14753)
- fix: track version in fingerprint dep-info files (rust-lang/cargo#14751)
- test: Remove unused msrv-policy (rust-lang/cargo#14748)
- download targeted transitive deps of with artifact deps'  target platform (rust-lang/cargo#14723)
- Remove requirement for --target when invoking Cargo with -Zbuild-std (rust-lang/cargo#14317)
- docs(fingerprint): document the encoding of Cargo's depinfo (rust-lang/cargo#14745)
- Allow build scripts to report error messages through `cargo::error` (rust-lang/cargo#14743)
- fix(publish): Downgrade version-exists error to warning on dry-run (rust-lang/cargo#14742)
- fix: clean up for deprecated and removed commands (rust-lang/cargo#14739)
- Deprecate `cargo verify-project` (rust-lang/cargo#14736)
@rustbot rustbot added this to the 1.84.0 milestone Nov 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-documenting-cargo-itself Area: Cargo's documentation S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants