Move host_info outside of requested_kinds is_host if statement.

Test that setting -Zhost-config without -Ztarget-applies-to-host fails.

Fix #9030 rebase.

Code cleanups for the split-host work

Add feature gate for target-applies-to-host.

Add target-applies-to-host and default to true unless host-config is enabled.

Document and feature-gate host-config tables.

Refactor host and target config table loads to deduplicate logic.

Configure hosts separately from targets when --target is specified.

This prevents target configs from accidentally being picked up when
cross compiling from hosts that have the same architecture as their
targets.

closes #3349

Auto merge of #9030 - Ekleog:target-setting, r=alexcrichton

Expose build.target .cargo/config setting as packages.target in Cargo.toml

Hey!

I'm trying to do my first cargo contribution by implementing per-crate target settings as per [the irlo thread](https://internals.rust-lang.org/t/proposal-move-some-cargo-config-settings-to-cargo-toml/13336) ; and I think I have a draft that looks good-ish (the root units returned by `generate_targets` have the right kinds set).

Closes #7004

**_Edit: the below problem description is now solved in the latest version of this PR, please ignore_**

But for some reason running on a test project now blocks on `Blocking waiting for file lock on build directory` and I have literally no idea how my changes could trigger this… would anyone have an idea of how the changes could lead to infinitely blocking there? (I already tried cargo clean just in case and it didn't appear to help)

FWIW, the output that looks hopeful to me is, on my testbed workspace:
```
Root units [out of generate_targets] are [...]:
 - package ‘smtp-client’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-server’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘yuubind-config’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-message-fuzz’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘yuubind-rpc’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘yuubind-config-example’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-message-fuzz’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘yuubind-config-example’ with kind ‘Target(CompileTarget { name: "wasm32-unknown-unknown" })’
 - package ‘smtp-queue’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-message-fuzz’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-message’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-server-fuzz’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘yuubind-config’ with kind ‘Target(CompileTarget { name: "wasm32-unknown-unknown" })’
 - package ‘yuubind’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-queue-fs’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
```
(where both `yuubind-config` and `yuubind-config-example` are being configured to be `wasm32-unknown-unknown` and the other ones stay as host).

Interestingly enough, if I remove the `target` setting from `yuubind-config` (and leave it on `yuubind-config-example`) then it does no longer block on waiting for file lock on build directory, even though it does not actually compile with `wasm32-unknown-unknown`. And it does appear to correctly build yuubind-config-example as wasm32.

My investigation shows that it appears to happen iff there is a package with `package.target` being set that has dependencies.

This most likely is a bug in my code (eg. I build only the root units and not the whole unit graph maybe?), and am going to keep investigating it as such, but maybe someone would already know how dependency resolution could interact with build lock acquisition and give me hints?

Anyway, thank you all for all you do cargo!

Auto merge of #9404 - ehuss:rustdoc-fingerprint-remove-dir, r=alexcrichton

Some changes to rustdoc fingerprint checking.

#8640 introduced a check which deletes the `doc` directory if cargo detects it has stale contents from a different toolchain version. Rustdoc has some shared files (js and css for example) that can get corrupted between versions. Unfortunately that caused some problems with rustbuild which does a few unusual things. Rustbuild will:

* Create the `doc` directory before running `cargo doc` and places a `.stamp` file inside it.
* Creates symlinks of the `doc` directory so that they can be shared across different target directories (in particular, between rustc and rustdoc).

In order to address these issues, this PR does several things:

* Adds `-Z skip-rustdoc-fingerprint` to disable the `doc` clearing behavior.
* Don't delete the `doc` directory if the rustdoc fingerprint is missing. This is intended to help with the scenario where the user creates a `doc` directory ahead of time with pre-existing contents before the first build. The downside is that cargo will not be able to protect against switching from pre-1.53 to post-1.53.
* Don't delete the `doc` directory itself (just its contents). This should help if the user created the `doc` directory as a symlink to somewhere else.
* Don't delete hidden files in the `doc` directory. This isn't something that rustdoc creates.

Only the `-Z` change is needed for rustbuild. The others I figured I'd include just to be on the safe side in case there are other users doing unusual things (and I had already written them thinking they would work for rustbuild). Hopefully the rustbuild `.stamp` mechanism will be enough protection there.

Fixes #9336

Auto merge of #9405 - Hawk777:cargo-pkg-for-build-scripts, r=ehuss

Document that CARGO_PKG_ are availble to build.rs

Fixes GH-9403.

fix build

Document that CARGO_PKG_ are availble to build.rs

handle review comments

Improve error message on missing feature gate

Expose build.target .cargo/config setting as packages.target in Cargo.toml

Add tests for new rustdoc fingerprint behavior.

Add -Zskip-rustdoc-fingerprint

This is a hidden flag intended to only be used by rustbuild which will
skip the rustdoc fingerprint check. rustbuild does some funky things
with sharing the doc directory across multiple target directories via
symlinks, and that causes problems where after building in one target
directory, then switching to the second one, it will clear the contents.

rustdoc fingerprint: don't delete the top directory

In some cases, the directory may actually be a symlink created by the
user, and we don't want to delete it. Also, skip any hidden files added
by the user as well.

Don't delete doc directories if the rustdoc fingerprint is missing.

This also rearranges the code a little bit to try to avoid some
duplication and to try to make it a little more compact.

Make doc_fingerprint_respects_target_paths work on all targets.

Auto merge of #9397 - alexcrichton:fix-hash, r=ehuss

Restore crates.io's `SourceId` hash value to before

This commit restores the hash value of the crates.io `SourceId` to what
it was before #9384. In #9384 the enum variants of `SourceKind` were
reordered which accidentally changed the hash value of the `SourceId`
for crates.io. A change here means that users with a new version of
Cargo will have to redownload the index and all crates, which is
something that we strive to avoid forcing.

In changing this, though, it required a manual implementation of `Ord`
to still contain the actual fix from #9384 which is to sort `SourceKind`
differently from how it's defined. I was curious as to why this was
necessary since it wasn't ever necessary in the past and this led to an
odd spelunking which turned up some interesting information. Turns out
Rust 1.47 and after had a breaking change where Cargo would sort
dependencies differently. This means that #9334 *could* have been opened
up much earlier, but it never was. We ironically only saw an issue when
we fixed this regression (although we didn't realize we were fixing a
regression). This means that we are now permanently codifying the
regression in Cargo.

Clarify some versions

Restore crates.io's `SourceId` hash value to before

This commit restores the hash value of the crates.io `SourceId` to what
it was before #9384. In #9384 the enum variants of `SourceKind` were
reordered which accidentally changed the hash value of the `SourceId`
for crates.io. A change here means that users with a new version of
Cargo will have to redownload the index and all crates, which is
something that we strive to avoid forcing.

In changing this, though, it required a manual implementation of `Ord`
to still contain the actual fix from #9384 which is to sort `SourceKind`
differently from how it's defined. I was curious as to why this was
necessary since it wasn't ever necessary in the past and this led to an
odd spelunking which turned up some interesting information. Turns out
Rust 1.47 and after had a breaking change where Cargo would sort
dependencies differently. This means that #9334 *could* have been opened
up much earlier, but it never was. We ironically only saw an issue when
we fixed this regression (although we didn't realize we were fixing a
regression). This means that we are now permanently codifying the
regression in Cargo.

Auto merge of #9392 - alexcrichton:fix-patch-git-head-issue, r=ehuss

Fix loading `branch=master` patches in the v3 lock transition

This commit fixes an issue pointed out during #9352 where in the v2->v3
lock file transition (currently happening on nightly) Cargo will not
correctly use the previous lock file entry for `[patch]` directives that
point to git dependencies using `branch = 'master'` explicitly. The
reason for this is that Cargo previously, with the v2 format, considered
`branch=master` and `DefaultBranch` to be equivalent dependencies. Now
that Cargo treats those as distinct resolve nodes we need to load lock
files that use `DefaultBranch` and transparently use those for
`branch=master` dependencies.

These lock file nodes do not naturally unify so we have to go out of our
way to get the two to line up in modern Cargo. This was previously done
for the lock file at large, but the previous logic didn't take `[patch]`
into account. Unfortunately almost everything to do with `[patch]` and
lock files is pretty complicated, and this is no exception. The fix here
is wordy, verbose, and quite subtle in how it works. I'm pretty sure it
does work though and I think that this should be good enough to at least
transition most users off the v2 lock file format. Once this has baked
in Cargo for some time (on the scale of a year) I would hope that we
could just remove this logic since it's only really here for a
transitionary period.

Closes #9352

Auto merge of #9396 - ehuss:changelog-1.52-beta, r=alexcrichton

Update changelog for 1.52 beta changes.

A few things were reverted on the beta branch.

Update changelog for 1.52 beta changes.

Auto merge of #9393 - ehuss:build-std-updating, r=alexcrichton

Fix build-std updating the index on every build.

https://github.com/rust-lang/rust/pull/83776 has caused a problem where build-std will update the index on every build. That PR added `std_detect` from the `stdarch` submodule as a path dependency of `std`. However, since `stdarch` has a workspace of its own, an exclusion had to be added to `Cargo.toml` so that it does not treat `std_detect` as a workspace member (because nested workspaces are not supported).

The problem is that the std `Cargo.lock` file is built thinking that `std_detect` is *not* a workspace member. This means that its dev-dependencies are not included. However, when cargo resolves the std workspace, it doesn't know that `std_detect` should be excluded, so it considers it a workspace member (because it is a path dependency). This means that it expects the dev-dependencies to be in Cargo.lock. Because they are missing, it ends up poisoning the registry and triggering an update:

> poisoning registry `https://github.com/rust-lang/crates.io-index` because std_detect v0.1.5 (/Users/eric/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/stdarch/crates/std_detect) looks like it changed auxv

The solution here is to skip dev-dependencies if they are not actively being resolved, even if the package is a workspace member.

This has happened before (#8962), so I have updated the test to check for it.

There are some alternative solutions I considered:

* Add support for nested workspaces. 😄
* Use a symlink to `std_detect` in the `rust-lang/rust` repository so that it appears to cargo as-if it is "outside" of the stdarch workspace, and thus can be treated like a normal workspace member (and remove the "exclude"). That seems a little hacky.

Fixes #9390

Fix build-std updating the index on every build.

Fix loading `branch=master` patches in the v3 lock transition

This commit fixes an issue pointed out during #9352 where in the v2->v3
lock file transition (currently happening on nightly) Cargo will not
correctly use the previous lock file entry for `[patch]` directives that
point to git dependencies using `branch = 'master'` explicitly. The
reason for this is that Cargo previously, with the v2 format, considered
`branch=master` and `DefaultBranch` to be equivalent dependencies. Now
that Cargo treats those as distinct resolve nodes we need to load lock
files that use `DefaultBranch` and transparently use those for
`branch=master` dependencies.

These lock file nodes do not naturally unify so we have to go out of our
way to get the two to line up in modern Cargo. This was previously done
for the lock file at large, but the previous logic didn't take `[patch]`
into account. Unfortunately almost everything to do with `[patch]` and
lock files is pretty complicated, and this is no exception. The fix here
is wordy, verbose, and quite subtle in how it works. I'm pretty sure it
does work though and I think that this should be good enough to at least
transition most users off the v2 lock file format. Once this has baked
in Cargo for some time (on the scale of a year) I would hope that we
could just remove this logic since it's only really here for a
transitionary period.

Closes #9352

Auto merge of #9386 - ehuss:ehuss-profile-typo, r=alexcrichton

Fix typo in profile docs

Fix typo in profile docs

Auto merge of #9384 - alexcrichton:fix-order, r=ehuss

Fix disagreement about lockfile ordering on stable/nightly

This commit fixes an issue where the order of packages serialized into a
lock file differs on stable vs nightly. This is due to a bug introduced
in #9133 where a manual `Ord` implementation was replaced with a
`#[derive]`'d one. This was an unintended consequence of #9133 and means
that the same lock file produced by two different versions of Cargo only
differs in what order items are serialized.

With #9133 being reverted soon on the current beta channel this is
intended to be the nightly fix for #9334. This will hopefully mean that
those projects which don't build with beta/nightly will remain
unaffected, and those affected on beta/nightly will need to switch to
the new nightly ordering when it's published (which matches the current
stable). The reverted beta will match this ordering as well.

Closes #9334

Auto merge of #9365 - jyn514:rustc-bootstrap-crate-name, r=ehuss

Don't give a hard error when the end-user specifies RUSTC_BOOTSTRAP=crate_name

Fixes https://github.com/rust-lang/cargo/issues/9362.
The whole point of https://github.com/rust-lang/rust/pull/77802/ was to allow specifying this granularly, giving a hard error defeats the point.

I didn't know how to check what targets were reverse-dependencies of build.rs, so I just unconditionally use the library name (and give a hard error for anything else, even if it's the name of one of the binaries). End-users can still opt-in with RUSTC_BOOTSTRAP=1, and no public binaries use RUSTC_BOOTSTRAP=1, so I don't think this a big deal in practice.

<details><summary>Script to verify all crates using RUSTC_BOOTSTRAP=1 have a library</summary>

```sh
curl https://pastebin.com/raw/fGQ97xP6 | cut -d / -f1 | grep -v shnatsel | grep -v cargo- | sed 's#-\([0-9]\)#/\1#' | xargs -i curl -s -I -L "https://docs.rs/{}/" -w "%{http_code}\n" -o/dev/null
```

It should output 20 200s in a row.

</details>

r? `@ehuss` cc `@mark-simulacrum`

I don't know what cargo's policy is for backports, but this should be backported to 1.52.

Auto merge of #9369 - PicoJr:fix-9350, r=ehuss

Fix #9350 (cargo build -Z help is missing options)

> Do not merge yet, some options are still undocumented.

Fix #9350 (cargo build -Z help is missing options)

Add a procedural macro to declare `CliUnstable` struct and provide help messages instead of hard-coding help in `src/bin/cargo/cli.rs`

> Flags documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html

Feedback welcome

Fix #9350 (cargo build -Z help is missing options)

> Do not merge yet, some options are still undocumented.

Fix #9350 (cargo build -Z help is missing options)

Add a procedural macro to declare `CliUnstable` struct and provide help messages instead of hard-coding help in `src/bin/cargo/cli.rs`

> Flags documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html

Feedback welcome

Fix disagreement about lockfile ordering on stable/nightly

This commit fixes an issue where the order of packages serialized into a
lock file differs on stable vs nightly. This is due to a bug introduced
in #9133 where a manual `Ord` implementation was replaced with a
`#[derive]`'d one. This was an unintended consequence of #9133 and means
that the same lock file produced by two different versions of Cargo only
differs in what order items are serialized.

With #9133 being reverted soon on the current beta channel this is
intended to be the nightly fix for #9334. This will hopefully mean that
those projects which don't build with beta/nightly will remain
unaffected, and those affected on beta/nightly will need to switch to
the new nightly ordering when it's published (which matches the current
stable). The reverted beta will match this ordering as well.

Closes #9334

Auto merge of #9379 - stanislav-tkach:patch-1, r=Eh2406

an struct -> a struct

SemVer Compatibility: an struct -> a struct

Auto merge of #9378 - ehuss:help-windows, r=alexcrichton

Handle man pages better on Windows.

If a user has `man` installed on Windows via msys/mingw/etc, then `cargo help <subcommand>` would fail with `No manual entry for C:\Users\User\AppData\Local\Temp\cargo-manlSKwTQ`.  This is because the cygwin universe does not handle windows-style paths and does not auto-translate in this scenario.

The solution here is to run the command from within the temp directory and use a relative path which *should* work on all platforms and environments. I tested on windows (powershell, cmd, and mingw), macos, and linux.

Fixes #9197

Handle man pages better on Windows.

Auto merge of #9368 - weihanglo:issue-9319, r=ehuss

fix: better error message when dependency/workspace member missing

May fix #9319

Auto merge of #9376 - nicolaiunrein:patch-1, r=alexcrichton

Fix typo in book

While reading I found a little typo in the docs and corrected it.

Fix typo in book

While reading I found a little typo in the docs and corrected it.

Auto merge of #9348 - matklad:wrapper-fingerprint, r=ehuss

Don't re-use rustc cache when RUSTC_WRAPPER changes

We cache initial `rustc --version` invocations, to speed up noop builds.

We check the mtime of `rustc` to bust the cache if the complier changed.
However, before this PR, we didn't look at mtimes of `RUSTC_WRAPPER` /
`RUSTC_WORKSPACE_WRAPPER`, so we could've re-use old cache with new
wrapper.

Auto merge of #9372 - weihanglo:missing-split-debuginfo-in-config, r=ehuss

doc: add split-debuginfo doc in config chapter

Follow up for https://github.com/rust-lang/cargo/pull/9224.

doc: add split-debuginfo doc in config chapter

Fix tests

minor cleanup

Use the library name to decide whether the override should be allowed from the top-level.

If there's no library, give a hard error unless features are
unconditionally allowed with RUSTC_BOOTSTRAP=1.

Use the crate name instead of the package name

This doesn't work because it uses the name of the build script, which is
always build_script_build. I'm not sure what to change it to - the name
of the library crate could be different than the name of the package,
and there could be multiple different crates being compiled in the same
package.

Don't give a hard error on RUSTC_BOOTSTRAP=crate_name

fix: more error context for missing dep of workspace member

fix: more context when failed to load workspace member

Auto merge of #9367 - weihanglo:refactor/remove-CargoResultExt, r=alexcrichton

refactor: remove `CargoResultExt`

All `chain_err` -> `with_context` are done by IDE refactoring.

- Remove `CargoResultExt`.
- Call `format!` instead of `anyhow::format_err!` to reduce unnecessary macro expansions.
https://github.com/rust-lang/cargo/blob/e870eac9967b132825116525476d6875c305e4d8/src/cargo/util/errors.rs#L12-L18

Auto merge of #9363 - ehuss:cargo-env-fingerprint, r=alexcrichton

Track "CARGO" in environment fingerprint.

There is an issue where if a package includes an `env!("CARGO")`, that value is not tracked in the fingerprint. If different cargos are used, it will not rebuild. This changes it so that the path to cargo will be tracked in the fingerprint if the CARGO env var is in the dep-info file.

This came up with rust's build system where it [tracks the env](https://github.com/rust-lang/rust/blob/60158f4a7cf3e3063df6127d3f0d206921d285b0/src/bootstrap/config.rs#L574). If you build rust once, and then change the `cargo` value in `config.toml` and try building again, it would not pick up the change which caused me some confusion.

In theory, cargo could fingerprint this every time, but I figure that could be disruptive and trigger needlessly in some situations.

This diff is a little bigger than I would like for such an obscure case.  As an alternative, I think rustbuild could just print `cargo:rerun-if-env-changed=CARGO`, but I figure this could potentially be useful for other projects.

refactor: remove unnecessary anyhow macro calls

refactor: remove CargoResultExt

Don't re-use rustc cache when RUSTC_WRAPPER changes

We cache initial `rustc --version` invocations, to speed up noop builds.

We check the mtime of `rustc` to bust the cache if the complier changed.
However, before this PR, we didn't look at mtimes of `RUSTC_WRAPPER` /
`RUSTC_WORKSPACE_WRAPPER`, so we could've re-use old cache with new
wrapper.

Track "CARGO" in environment fingerprint.

Auto merge of #9356 - ehuss:clippy-allow, r=Eh2406

Update clippy lint allow set.

This updates the clippy lints to default allow. We would prefer not to take clippy lint PRs at this time as there are a number of false positives and subjective style changes that we would rather not review.

I left a couple lints as `warn` that I have found useful when refactoring.

Update testsuite/main.rs lint comment.

Update 2018 idioms comment.

Update clippy lint allow set.

Auto merge of #9338 - tniessen:typo-doc-suport, r=ehuss

Fix 'suport' typo in documentation

Fix 'suport' typo in documentation

Auto merge of #9328 - ehuss:contrib-typo, r=Eh2406

Fix typo in contrib docs.

😳

Fix typo in contrib docs.

Auto merge of #9323 - matthiaskrgr:clippy_v19, r=ehuss

fix clippy warnings

fixes these clippy warnings:

map_collect_result_unit
needless_borrow
needless_return
into_iter_on_ref
manual_flatten
match_like_matches_macro
bool_comparison

Auto merge of #9283 - jonhoo:z-allowed-features, r=ehuss

Add -Zallow-features to match rustc's -Z

This PR implements the `-Zallow-features` permanently-unstable feature flag that explicitly enumerates which unstable features are allowed (assuming unstable features are permitted in the first place). This mirrors the `-Zallow-features` flag of `rustc` which serves the same purpose for `rustc` features:

https://github.com/rust-lang/rust/blob/5fe790e3c40710ecb95ddaadb98b59a3bb4f8326/compiler/rustc_session/src/options.rs#L856-L857

This flag makes it easier to beta-test unstable features "safely" by ensuring that only a single unstable feature is used if you only have control over build system, and not the source code that developers may end up using, as discussed in [this internals thread](https://internals.rust-lang.org/t/mechanism-for-beta-testing-unstable-features/14280).

fix clippy warnings

fixes these clippy warnings:

map_collect_result_unit
needless_borrow
needless_return
into_iter_on_ref
manual_flatten
match_like_matches_macro
bool_comparison

Don't use RUSTC_BOOTSTRAP for nightly-only tests

Merge remote-tracking branch 'upstream/master' into z-allowed-features

Auto merge of #9316 - ehuss:fix-semver-1.51, r=alexcrichton

Fix semver docs for 1.51.

1.51 slightly changed the text of a few error messages. This should get CI passing again.

Fix semver docs for 1.51.

Fix after merge

Merge remote-tracking branch 'upstream/master' into z-allowed-features

Future-proof tests

Print features without Debug

Handle allow-features in add()

Sort feature list

Move from match guard to if

Include allowed features in fingerprint

If this weren't the case, a user that compiled, and then re-ran cargo
with a particular set of allowed features would not see any breakage
even if other unstable features were used.

The downside of this is that changing allow-features causes a full
re-compile, but that still _seems_ like the right thing to do.

Forward -Zallow-features inside mod compiler

util: Add iterator join method

Auto merge of #9302 - ehuss:cargo-config, r=alexcrichton

Add `cargo config` subcommand.

This adds an initial version of the `cargo config` command as discussed in #2362.

Closes #2362

Print environment note for json format, too.

Auto merge of #9313 - matklad:feat-doc, r=ehuss

Give one more example for the --featuers CLI

The previous example confused me because I thought that `foo-feat` is
the syntax for `foo/feat`. The "explicit" example should clarify that.

closes #9305

Give one more example for the --featuers CLI

The previous example confused me because I thought that `foo-feat` is
the syntax for `foo/feat`. The "explicit" example should clarify that.

closes #9305

Remove duplicate code.

Auto merge of #9308 - ehuss:version-bump, r=alexcrichton

Bump to 0.54.0, update changelog

Auto merge of #9309 - sciguy16:out_dir_issue_url, r=ehuss

Make the URL to the tracking issue for `--out-dir` into a link

Make the URL to the tracking issue for `--out-dir` into a link

Update changelog for 1.52

Bump to 0.54.0

Auto merge of #9307 - ijackson:exit-code-string, r=joshtriplett

tests: Tolerate "exit status" in error messages

"exit code" is wrong terminology on Unix.  I am trying to fix this in Rust stdlib in https://github.com/rust-lang/rust/pull/83462 but this currently breaks the cargo test suite.

See that MR for full explanation of the change.

tests: Tolerate "exit status" in error messages

"exit code" is wrong terminology on Unix.  I am trying to fix this in
Rust stdlib in
    https://github.com/rust-lang/rust/pull/83462
but this currently breaks the cargo test suite.

See that MR for full explanation of the change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Auto merge of #9298 - alexcrichton:mac-split-debuginfo-default, r=ehuss

Default macOS targets to `unpacked` debuginfo

This commit continues the work from #9112 to enable `unpacked` split
debuginfo on macOS targets by default. This has been discussed on [internals]
for awhile now and no breakage has emerged while significant speedups
have. This is expected to be a compile-time and `target`-directory size
win for almost all macOS Rust projects.

While breakage is possible it's possible to mitigate this with
project-local or global cargo configuration of the `dev` and `test` profiles.

[internals]: https://internals.rust-lang.org/t/help-test-faster-incremental-debug-macos-builds-on-nightly/14016/9

Default macOS targets to `unpacked` debuginfo

This commit continues the work from #9112 to enable `unpacked` split
debuginfo on macOS targets by default. This has been discussed on [internals]
for awhile now and no breakage has emerged while significant speedups
have. This is expected to be a compile-time and `target`-directory size
win for almost all macOS Rust projects.

While breakage is possible it's possible to mitigate this with
project-local or global cargo configuration of the `dev` and `test` profiles.

[internals]: https://internals.rust-lang.org/t/help-test-faster-incremental-debug-macos-builds-on-nightly/14016/9