Read a real target spec JSON so we no longer need to hardcode
a target spec JSON here.
Cargo itself should not care about the spec schema.
Let's stop bothering compiler contributors.
This is not necessary, as 32 is the default, and actually of the wrong
type now since it's a number now.
When planning to make these type mismatches error, cargo would fail
here, so I just removed it.
This custom target test very much shows how Cargo should be a subtree,
in this case it was fine because there's a compatible fix that I can
push now, otherwise it would have been very annoying.
rust-lang/rust#122565 adds a new line to thread panic output.
To make the current test suites works on stable, beta, and nightly,
similar to rust-lang/cargo#14602,
this relaxes the assertion around that by globbing everything.
This is kinda a revert of 125e873dffc4b68b263c5decd88750ec10fd441e
in terms of the behavior.
After this, now `std_resolve` is always resolved by the same set of
packages that Cargo will use to generate the unit graph, (technically
the same set of crates + `sysroot`), by sharing the same set of primary
packages via `std_crates` functions.
This failed because since 125e873dffc4b68b263c5decd88750ec10fd441e
[`std_resolve`][1] only includes `sysroot` as primary package.
When any custom Cargo feature is provided via `-Zbuild-std-feature`,
the default feature set `panic-unwind` would be gone, so no
`panic_unwind` crate presents in `std_resolve`.
When then calling [`std_resolve.query`][2] with the default set of
crates from [`std_crates`][3], which automatically includes
`panic_unwind` when `std` presents, it'll result in spec not found
because `panic_unwind` was not in `std_resolve` anyway.
[1]: addcc8ca71/src/cargo/core/compiler/standard_lib.rs (L96)
[2]: addcc8ca71/src/cargo/core/compiler/standard_lib.rs (L158)
[3]: addcc8ca71/src/cargo/core/compiler/standard_lib.rs (L156)
See rust-lang/cargo#14935
47c2095b1dd580a91e42cb6197b58a318526b8c4 didn't really fix the flakiness.
build-std tests use the users `CARGO_HOME` for downloading registry
dependencies of the standard library. This reduces disk needs of the
tests, speeds up the tests, and reduces the number of network requests
that could fail.
However, this means all of the tests access the same locks for the
package cache. In one test, we assert on the output and a `[BLOCKING]`
message can show up, depending on test execution time from concurrent
test runs.
We are going to hack around this by having the one test that asserts
on test output to use the standard `cargo-test-support` `CARGO_HOME`,
rather than the users `CARGO_HOME`. There will then only be one process
accessing the lock and no `[BLOCKING]` messages.
Remove requirement for --target when invoking Cargo with -Zbuild-std
This PR addresses [this issue](https://github.com/rust-lang/wg-cargo-std-aware/issues/25) 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`.
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 commit improves Cargo's support for git repositories whose "main
branch" is not called `master`. Cargo currently pretty liberally assumes
that if nothing else about a git repository is specified then `master`
is the branch name to use. Instead now Cargo has a fourth option as the
desired reference of a repository named `DefaultBranch`. Cargo doesn't
know anything about the actual name of the default branch, it just
updates how git references are fetched internally.
This commit is motivated by news that GitHub is likely to switch away
from the default branch being named `master` in the near future. It
would be a bit of a bummer if from now on everyone had to type
`branch = '...'`, so this tries to improve that!
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.
