`test_std_on_unsupported_target` never really succeed to build those targets, due to
* local rustup may not have `{aarch64,x86_64}-unknown-none` installed.
* `core` and `compiler-builtins` mock crate are not `no_std` nor `no_core`
* the dummy `main.rs` uses `println!` and is not `no_std`.
This commit make it compile, if you have those targets installed.
**What does this PR try to resolve?**
Ensures that Cargo first verifies whether a given target supports
building the standard library when the `-Zbuild-std=std` option is
passed to Cargo ([see issue
here](https://github.com/rust-lang/wg-cargo-std-aware/issues/87)). This
information can be obtained by querying `rustc
--print=target-spec-json`. The target spec "metadata" contains an
`Option<bool>` determining whether the target supports building std.
In the case this value is `false`, cargo will stop the build. This
avoids the numerous "use of unstable library" errors, giving a cleaner,
and simpler, "building std is not supported on this target".
**How should we test and review this PR?**
It can be manually tested by running `cargo build --target <target>
-Zbuild-std=std`. If a target who's target-spec marks std as false is
passed, cargo will exit. This works with multiple `--target`'s, and if
any of them don't support std, cargo will exit.
**Additional Information**
This change relies on two things:
* The target-spec metadata in rustc needs to be filled out. Currently,
most fields are None, which is treated as OK with this change. Meaning
this can be merged before the rustc changes.
* The new test case added with this change will fail without at least
`aarch64-unknown-none` having it's target-spec metadata completed.
* Some targets have std support marked as "?". If this state is properly
represented in the target-spec in the future, it needs to be determined
whether this is allowed, so the build can continue, or whether it fails.
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.
rust-lang/cargo#14358 didn't check the correct Cargo.lock existence
Perhaps it was there so the test passed, but after a new nightly
is out it is gone.
```
Blocking waiting for file lock on package cache
error: "/home/user/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/Cargo.lock" does not exist, unable to build with the standard library, try:
rustup component add rust-src --toolchain nightly-aarch64-apple-darwin
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
We now include the prelude in so many places, this simplifies how we can
present how `cargo-test-support` works.
Yes, this included some `use` clean ups but its already painful enough
walking through every test file, I didn't want to do it twice.
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
This allows downloading the dependencies for libstd in advance, which
can be useful in e.g. sandboxed build environments.
- Abstract check for `--target` out into a function
- Try to abstract `test` special-casing into a function
This avoids hard-coding crate names in multiple places.
- Unify handling of checks for `--target` in `BuildConfig::new`
This makes sure it's checked consistently, without requiring each new command to check it explicitly.
- Share more code between `fetch` and `build` by adding `std_crates()`
- Warn about `--build-plan` and `-Zbuild-std` consistently, not just for `build`
Currently only `build` uses build-plan. But cargo may choose to add it to new commands in the future (e.g. check and doc).
Future-proof it, since it's simple to do.
This flag is intended to pair with `-Zbuild-std` as necessary to
configure the features that libstd is built with. This is highly
unlikely to ever be stabilized in any form (unlike `-Zbuild-std` which
we'd like to stabilize at some point), but can be useful for
experimenting with the standard library. For example today it can be
used to test changes to binary size by disabling backtraces.
My intention is that we won't need a `--no-default-features` equivalent
for libstd, where after rust-lang/rust#74377 is merged we can
unconditionally specify default features are disabled but the default
set of features lists `default`. That way if users want to override the
list *and* include the default feature, they can just be sure to include
`default`.
This commit refactors the internals of Cargo to no longer have a
singular `--target` flag (and singular `requested_target` kind throught)
but to instead have a list. The semantics of multiple `--target` flags
is to build the selected targets for each of the input `--target` flag
inputs.
For now this is gated behind `-Zmultitarget` as an unstable features,
since I'm not entirely sure this is the interface we want. In general
it'd be great if we had a way to simply specify `Unit` structures of
what to build on the CLI, but we're in general very far away from that,
so I figured that this is probably sufficient at least for testing for
now.
cc #8156
Use associated constants directly on primitive types instead of modules
This PR is in no way critical. It's more of a code cleanup. It comes as a result of me making https://github.com/rust-lang/rust/pull/70857 and search-and-replacing all usage of the soft-deprecated ways of reaching primitive type constants.
It makes the code slightly shorter, that's basically it. And showcases the recommended way of reaching these consts on new code :)
* Minimize the sysroot crates in play
* Don't use build scripts to inject args
* Use `RUSTC_WRAPPER` to dynamically switch `--sysroot` depending on
whether we're building sysroot crates or not.
* Minimize dependency graph in sysroot, only have each crate depend on a
dummy crates.io crate for testing and otherwise don't depend on
anything to load the desired sysroot crate directly.
Only run these tests on one CI builder (not all platforms) though. This
is extremely resource intensive since it rebuilds libstd. Currently this
does not share a build directly like before because the number of tests
are supposed to be small, but if necessary we can add that in later too.
This commit is aimed directly at rust-lang/wg-cargo-std-aware#33 and in
general making the `-Zbuild-std` tests more robust. The main change here
is that a new source tree is checked in, `tests/testsuite/mock-std`,
which mirrors rust-lang/rust's own tree for libstd. This mock tree is as
empty as it can be, ideally duplicating almost nothing but for not
requiring duplication of Cargo metadata about patches and such.
The end result here looks like:
* All `-Zbuild-std` tests are now run in parallel
* All tests run much more quickly since they're compiling tiny crates
instead of actually compiling libstd/libcore
* No tests require network access
* We verify that crates have access to the "custom" libraries
that we build
Coverage of tests is not currently expanded, but it's hoped that we
could add that shortly afterwards. Coverage has actually gone down
slightly since the custom target test was commented out temporarily and
the full integration test of running `-Zbuild-std` isn't run on CI any
more.
Closesrust-lang/wg-cargo-std-aware#33
