Auto merge of #9229 - alexcrichton:fix-borrow-mut, r=ehuss

Fix a `BorrowMut` error when stdout is closed

There was one location in the job queue where the shell is borrowed
twice by accident, so instead hold the same borrow over both locations.

Closes #9220

Fix a `BorrowMut` error when stdout is closed

There was one location in the job queue where the shell is borrowed
twice by accident, so instead hold the same borrow over both locations.

Closes #9220

Auto merge of #8825 - Aaron1011:feature/report-future-incompat, r=ehuss

Implement future incompatibility report support

cc rust-lang/rust#71249

This implements the Cargo side of 'Cargo report future-incompat'

Based on feedback from alexcrichton and est31, I'm implemented this a
flag `--future-compat-report` on `cargo check/build/rustc`, rather than
a separate `cargo describe-future-incompatibilities` command. This
allows us to avoid writing additional information to disk (beyond the
pre-existing recording of rustc command outputs).

This PR contains:

* Gating of all functionality behind `-Z report-future-incompat`.
  Without this flag, all user output is unchanged.
* Passing `-Z emit-future-incompat-report` to rustc when
  `-Z report-future-incompat` is enabled
* Parsing the rustc JSON future incompat report, and displaying it
  it a user-readable format.
* Emitting a warning at the end of a build if any crates had
  future-incompat reports
* A `--future-incompat-report` flag, which shows the full report for
  each affected crate.
* Tests for all of the above.

At the moment, we can use the `array_into_iter` to write a test.
However, we might eventually get to a point where rustc is not currently
emitting future-incompat reports for any lints. What would we want the
cargo tests to do in this situation?

This functionality didn't require any significant internal changes to
Cargo, with one exception: we now process captured command output for
all units, not just ones where we want to display warnings. This may
result in a slightly longer time to run `cargo build/check/rustc` from
a full cache. since we do slightly more work for each upstream
dependency. Doing this seems unavoidable with the current architecture,
since we need to process captured command outputs to detect
any future-incompat-report messages that were emitted.

Add future-incompat tracking issue number.

Fix some minor formatting issues.

Address review comments

Implement future incompatibility report support

cc rust-lang/rust#71249

This implements the Cargo side of 'Cargo report future-incompat'

Based on feedback from alexcrichton and est31, I'm implemented this a
flag `--future-compat-report` on `cargo check/build/rustc`, rather than
a separate `cargo describe-future-incompatibilities` command. This
allows us to avoid writing additional information to disk (beyond the
pre-existing recording of rustc command outputs).

This PR contains:

* Gating of all functionality behind `-Z report-future-incompat`.
  Without this flag, all user output is unchanged.
* Passing `-Z emit-future-incompat-report` to rustc when
  `-Z report-future-incompat` is enabled
* Parsing the rustc JSON future incompat report, and displaying it
  it a user-readable format.
* Emitting a warning at the end of a build if any crates had
  future-incompat reports
* A `--future-incompat-report` flag, which shows the full report for
  each affected crate.
* Tests for all of the above.

At the moment, we can use the `array_into_iter` to write a test.
However, we might eventually get to a point where rustc is not currently
emitting future-incompat reports for any lints. What would we want the
cargo tests to do in this situation?

This functionality didn't require any significant internal changes to
Cargo, with one exception: we now process captured command output for
all units, not just ones where we want to display warnings. This may
result in a slightly longer time to run `cargo build/check/rustc` from
a full cache. since we do slightly more work for each upstream
dependency. Doing this seems unavoidable with the current architecture,
since we need to process captured command outputs to detect
any future-incompat-report messages that were emitted.

Auto merge of #9022 - nagisa:nagisa/manifest_path, r=alexcrichton

Add the path to the manifest in json output

This allows consumers of the json messages to avoid guessing where
exactly the package root is. Having access to the package root is
difficult by virtue of requiring logic to guess its location by e.g.
walking filesystem from the source file.

This guessing logic becomes further complicated in presence of
workspaces and nigh impossible to implement correctly in instances where
artifacts end up produced from paths above the package root (e.g.
`../foo.rs`).

Since Cargo has access to this data in the first place, there doesn't
seem to be much reason to force consumers to invent their own, possibly
flawed, logic.

Add the path to the manifest in json output

This allows consumers of the json messages to avoid guessing where
exactly the package root is. Having access to the package root is
difficult by virtue of requiring logic to guess its location by e.g.
walking filesystem from the source file.

This guessing logic becomes further complicated in presence of
workspaces and nigh impossible to implement correctly in instances where
artifacts end up produced from paths above the package root (e.g.
`../foo.rs`).

Since Cargo has access to this data in the first place, there doesn't
seem to be much reason to force consumers to invent their own, possibly
flawed, logic.

Auto merge of #9230 - kornelski:nobinaries, r=alexcrichton

Explain `cargo install` is not for libraries

On a few occasions I've seen novice users assume that `cargo install` works like `npm install` or `apt install`, and they're confused that they can't use library dependencies this way.

I've expanded the error message to hopefully clarify the misconception.

Auto merge of #9236 - kornelski:track-assert, r=Eh2406

track_caller on custom assert functions

This makes test helper functions point to the failing test, rather than internals of a function that did some checking.

track_caller on custom assert functions

Explain `cargo install` is not for libraries

Auto merge of #9231 - joshtriplett:clear-to-eol-if-color, r=alexcrichton

Use ANSI clear-to-EOL if color is force-enabled

When running cargo with output not going to a TTY, and with the progress
bar and color force-enabled, this makes cargo clean up its right-aligned
output properly.

This doesn't fix the case where progress is force-enabled and color
isn't, but it fixes the case where both are force-enabled.

Auto merge of #9181 - jyn514:computer-says-no, r=ehuss

Forbid setting `RUSTC_BOOTSTRAP` from a build script on stable

Instead, recommend `RUSTC_BOOTSTRAP=crate_name`. If cargo is using a nightly toolchain, or if RUSTC_BOOTSTRAP was set in *cargo*'s build environment, the error is downgraded to a warning, since the variable won't affect the build.

This is mostly the same as suggested in https://github.com/rust-lang/cargo/issues/7088#issuecomment-713867773, except that `RUSTC_BOOTSTRAP=` values other than 1 are treated the same as `RUSTC_BOOTSTRAP=1`. My reasoning was that https://github.com/rust-lang/rust/pull/77802 is now on 1.50 stable, so some crates may have started using it, and I would still prefer not to give hard errors when there's no workaround.

Closes https://github.com/rust-lang/cargo/issues/7088.

r? `@joshtriplett`

Remove unhelpful link to Cargo book

It didn't have any information about RUSTC_BOOTSTRAP itself, only the
general `rustc-env` feature.

Use ANSI clear-to-EOL if color is force-enabled

When running cargo with output not going to a TTY, and with the progress
bar and color force-enabled, this makes cargo clean up its right-aligned
output properly.

This doesn't fix the case where progress is force-enabled and color
isn't, but it fixes the case where both are force-enabled.

Auto merge of #9226 - matklad:utf8everywhere, r=alexcrichton

Don't panic when printing JSON with non-utf8 paths

Before:

    λ cd \Xff/foo/ && cargo verify-project && cargo metadata
    {"success":"true"}
    warning: please specify `--format-version` flag explicitly to avoid compatibility problems
    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("path contains invalid UTF-8 characters", line: 0, column: 0)', /rustc/a5a775e3f9e8043dad405e00aee0ae60882a7b71/src/tools/cargo/src/cargo/core/shell.rs:346:51
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

After:

    λ cd \Xff/foo/ && $cargo verify-project && $cargo metadata
    {"success":"true"}
    warning: please specify `--format-version` flag explicitly to avoid compatibility problems
    error: path contains invalid UTF-8 characters

I am pretty  sure that this has zero real-world impact, but the diff is
small, so why not handle it?

Don't panic when printing JSON with non-utf8 paths

Before:

    λ cd \Xff/foo/ && cargo verify-project && cargo metadata
    {"success":"true"}
    warning: please specify `--format-version` flag explicitly to avoid compatibility problems
    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("path contains invalid UTF-8 characters", line: 0, column: 0)', /rustc/a5a775e3f9e8043dad405e00aee0ae60882a7b71/src/tools/cargo/src/cargo/core/shell.rs:346:51
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

After:

    λ cd \Xff/foo/ && $cargo verify-project && $cargo metadata
    {"success":"true"}
    warning: please specify `--format-version` flag explicitly to avoid compatibility problems
    error: path contains invalid UTF-8 characters

I am pretty  sure that this has zero real-world impact, but the diff is
small, so why not handle it?

Auto merge of #9223 - ehuss:fingerprint-target, r=alexcrichton

Detect changes for JSON spec targets.

This adds the contents of a JSON spec target file to the fingerprint hash so that changing the contents will trigger a rebuild. This also deals with the target info cache in a similar fashion.

Closes #2616

Auto merge of #9225 - ehuss:fix-target-dir-env-test, r=alexcrichton

Fix `cargo_target_empty_cfg` test with env var.

The test `cargo_target_empty_cfg` does not work if the environment variable `CARGO_TARGET_DIR` is set. `Config` should not be looking at the "real" environment, but instead `self.env` which is controlled during tests.

I also did some minor style/cleanup changes.

Unblocks upstream sync.

Fix `cargo_target_empty_cfg` test with env var.

Auto merge of #9202 - gauntface:patch-1, r=ehuss

Correct default cargo new edition

I think this is a small typo in the docs but feel free to close this PR if I'm mistaken

Auto merge of #9224 - ehuss:split-debuginfo-docs, r=Eh2406

Update split-debuginfo docs around the default.

The default behavior was changed during the course PR #9112, but the docs weren't updated.

Closes #9218

Update split-debuginfo docs around the default.

Detect changes for JSON spec targets.

Auto merge of #9213 - ehuss:registry-api-errors, r=alexcrichton

Minor update to registry API error messages.

This is a minor update to the registry API errors, trying to make them a little clearer and more helpful. My concerns were:

* `api errors (status 200 OK): some error message` — why was there both an error and 200 OK?
* `api errors` — What is an "api error" anyways?  The user is probably not familiar with the "registry API".
* Adds the URL of the server it is actually talking to, in case you may be confused when using a registry other than crates.io. This also tries to make it clearer that the message is coming from the remote server, and not cargo itself.

Auto merge of #9214 - ehuss:clippy-cleanup, r=Eh2406

Some minor code cleanup.

Some cleanup as recommended by clippy.  I think most of these are a little cleaner, though sometimes it is hard call.

Some minor code cleanup.

Minor update to registry API error messages.

Auto merge of #9212 - vidbina:fix-spelling-worksapce-to-workspace, r=ehuss

doc: Fix spelling worksapce->workspace

only in comments or documentation

doc: Fix spelling worksapce->workspace

only in comments or documentation

Auto merge of #9209 - ehuss:update-spdx, r=alexcrichton

Update SPDX version in docs.

The version is being updated in https://github.com/rust-lang/crates.io/pull/3335.

Update SPDX version in docs.

Auto merge of #8939 - Andy-Python-Programmer:master, r=alexcrichton

Throw error if CARGO_TARGET_DIR is an empty string

This pull request makes the target dir to be target/ if `CARGO_TARGET_DIR` is `` with spaces trimmed and not delete the current project.

Fixes: #8866

Auto merge of #9207 - ehuss:testsuite-splitdebug, r=Eh2406

testsuite: Use split debuginfo on macos.

This switches the testsuite to use "unpacked" debuginfo on macos, which is a substantial performance boost. On my system, the testsuite runs 1.55 times faster with this change.  Along with #9206, total testsuite time is 3.1 times faster.

Remove unnecessary `config` argument to `Features::add`

The info was already present on `self`.

Note that this uses a temporary variable to avoid a borrowck error from
`slot`.

Auto merge of #9206 - ehuss:testsuite-rustup, r=Eh2406

testsuite: Improve performance when using rustup.

The rustup wrapper adds a considerable amount of overhead when running processes like `rustc`.  This overrides `PATH` when running the testsuite to prioritize the actual executables to avoid the wrapper.

I'm not 100% confident this won't break something somewhere, but it seems like it should be safe.

In my tests, this makes the testsuite 1.5 to 1.7 times faster.

testsuite: Improve performance when using rustup.

testsuite: Use split debuginfo on macos.

Fix tests

Fixes error message

Update manifest.md

Based on feedback, removed invalid value statement.

Fix TODO about nightly features

Be less unix-centric in error messages

Co-authored-by: Eric Huss <eric@huss.org>

Fix test that assumed tests always were run on the stable channel

Note that this has to be set in the builder, before
`config.configure()` gets run.

Update comment in build_script_env

Make `nightly_features_allowed` a field instead of a function

`nightly_features_allowed()` is no longer doing any work, so it can be
accessed directly. This also renames the `enable_nightly_features` field
to `nightly_features_allowed`.

Compute `enable_nightly_features` once instead of on each call

This avoids reparsing `channel()` over and over again. It also makes
`maybe_enable_nightly_features` unnecessary and removes it.

Remove unused thread_locals

Fix `masquerade_as_nightly_cargo` in work threads

Previously, since `ENABLE_NIGHTLY_FEATURES` and
`NIGHTLY_FEATURES_ENABLED` were thread locals, reading them in any other
thread would always say nightly features were disabled. Now, they are
tied to the `Context` itself, so it is both more clear how the variables
are being set and fixes the behavior within work threads.

Note that `Context` is not thread-safe, so this passes a boolean through
to `BuildOutput::parse`.

Suggest RUSTC_BOOTSTRAP=crate instead of RUSTC_BOOTSTRAP=1

This was the whole point of https://github.com/rust-lang/rust/pull/77802.

- Pass `pkg.name()` to `parse()`. This can't pass the `Package` directly
  because `PackageInner` is an `Rc` and therefore not thread-safe. Note
  that `pkg_name` was previously a *description* of the package, not the
  name passed with `--crate-name`.

Downgrade error to a warning when `RUSTC_BOOTSTRAP` is set or this is the nightly channel

Restrict RUSTC_BOOTSTRAP in build.rs

Auto merge of #9128 - poliorcetics:respect-shortness-rustdoc, r=ehuss

Pass the error message format to rustdoc

- Goes with rust-lang/rust#81675.
- Will help with rust-lang/rust#81662.

This is my first PR to Cargo and I haven't finished reading the contributor guide yet, how should I add tests for this ? Did I had the code in the correct place ?

Auto merge of #9203 - ehuss:fix-target_in_environment_contains_lower_case, r=alexcrichton

Fix test target_in_environment_contains_lower_case

This test will fail if you actually have the x86_64-unknown-linux-musl target installed.  Instead of assuming it will fail, this uses the host target instead, which should only fail on windows due to case-insensitive environment keys.

Add tests

Auto merge of #9201 - ehuss:close-error-during-drain, r=Eh2406

Fix hang on broken stderr.

If stderr is closed and cargo tries to print a status message such as "Compiling", cargo can get into a hung state. This is because the `DrainState::run` function would insert the job into the `active` queue, and then return an error without starting the job. Since the job isn't started, there is nothing to remove it from the `active` queue, and thus cargo hangs forever waiting for it to finish.

The solution is to move the call to `note_working_on` earlier before the job is placed into the active queue.

This addresses the issue noted in https://github.com/rust-lang/cargo/issues/8714#issuecomment-783787163.

Update manifest.md

Another alterations after pondering further

Update manifest.md

Suggestion for text when the edition isn't defined at all

Auto merge of #9195 - guswynn:test_name, r=ehuss

Make it more clear which module is being tested when running cargo test

I recently asked in zulip if this is a good idea, as I find it hard to find the module thats being tested from the complex path with the hash.

Output of `cargo test`:
```
2021-02-21 13:29:33 I > ~/repos/cargo/target/debug/cargo test
    Finished test [unoptimized + debuginfo] target(s) in 0.42s
     Running unittests (target/debug/deps/test_tests-759130ea61f71571)

running 1 test
test tests::unit_test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in
0.00s

     Running tests2/lib.rs (target/debug/deps/integration_tests-6b7f9fcd1721f083)

running 2 tests
test tests2_lib ... ok
test second_test::tests2_second ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in
0.00s

     Running tests/lib.rs (target/debug/deps/lib-d2be6d29597c2790)

running 2 tests
test second_test::tests_i_am_run_twice ... ok
test tests_lib ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in
0.00s
...
```

Correct default cargo new edition

I think this is a small typo in the docs but feel free to close this PR if I'm mistaken

Fix test target_in_environment_contains_lower_case

Fix hang on broken stderr.

Auto merge of #9184 - ehuss:fix-next-edition, r=alexcrichton

Updates to edition handling.

This introduces some updates for edition handling (split into commits for review).  In short:

* `cargo-features = ["edition2021"]` can be used to opt-in to 2021 support without needing to pass around `-Z unstable-options`. I tried to emphasize in the docs that this is only for testing and experimentation.
* Make `"2"` the default resolver for 2021 edition.
* Make `cargo fix --edition` mean the "next" edition from the present one, and support 2021. Also, if already at the latest edition, generate a warning instead an error.
* I decided to allow `cargo fix --edition` from 2018 to 2021 on the nightly channel without an explicit opt-in. It's tricky to implement with an opt-in (see comment in diff).

Partial for #9048.
Fixes #9047.

Auto merge of #9002 - volks73:feature-rustc-cfg-argument, r=alexcrichton

Add --cfg and --rustc-cfg flags to output compiler configuration

This PR is my attempt to address #8923.

I have added the `--cfg` flag to the `cargo rustc` subcommand and the `--rustc-cfg` flag to the `cargo build`, `cargo check`, `cargo test`, and `cargo bench` subcommands, respectively. Both versions of the flag, `--cfg` and `--rustc-cfg`, do the same thing, but I thought it looked weird for the `cargo rustc` subcommand to be `cargo rustc --rustc-cfg`. The following example invocations are possible, once stabilized:

- `cargo rustc --cfg`
- `cargo build --rustc-cfg`
- `cargo check --rustc-cfg`
- `cargo test --rustc-cfg`
- `cargo bench --rustc-cfg`

In each case, compilation is aborted and only compiler configuration is emitted. All of the context creation and configuration is still executed, but execution of the compilation job is aborted. Similar to the `--unit-graph` implementation, the `--cfg/--rustc-cfg` flag is hidden, marked as a "unstable", and requires the `-Z unstable-options` flag at the moment. A complete example invocation with this PR would be:

```bash
$ cargo +nightly rustc -Z unstable-options --cfg
```

I am open to alternatives for the flag name. I have thought of `--compiler-cfg`, `--compile-cfg`, and `--target-cfg`, but I went with `--rustc-cfg` because it is the Rust compiler (rustc) configuration (cfg). The `--target-cfg` could be confusing because there are Cargo targets and Compiler targets. A lone `--cfg` for the build, check, test, and bench subcommands would also be ambiguous and configuration that is being displayed.

Originally, I was only going to add the `--cfg` flag to the `cargo rustc` subcommand, but build, check, test, and bench all have the `--unit-graph` flag, and I used that flag's implementation and existence as a template for this implementation. I am not opposed to having just the `--cfg` flag for the `cargo rustc` subcommand as originally proposed in #8923.

I discovered during my initial investigation to implement the feature and familiarization with the Cargo codebase, that as part of the build context creation and compilation process, Cargo internally calls the `rustc --print cfg` command for all targets and stores the output in the `RustcTargetData` type. It does this for the host and any explicitly defined targets for cross-compilation. Compilation features, such as `+crt-static`, added to the compilation process through Cargo environment variables or TOML configuration directives are added to the internal `rustc --print cfg` command call. So, the `--cfg/--rustc-cfg` just emits the contents of the `RustcTagetData` type as JSON. There is no need to call the `rustc --print cfg` command again. The implementation then becomes nearly identical to the `--unit-graph` implementation.

The output is only in JSON, similar to the `--unit-graph` feature, instead of the key-value and name style of the `rustc --print cfg` output because it easily resolves issues related to multi-targets, explicit target (`--target <TRIPLE>`) versus host configurations, and cross compilation. Subcommands and other projects can parse the JSON to recreate the key-value and name style if desired based on a specific target or the host. Here is an example of the JSON output (formatted for humans, the actual output is condensed), which is also available as a comment in the `cargo::core::compiler::rustc_cfg` module:

```javascript
{
     "version": 1,
     "host": {
         "names": ["windows", "debug_assertions"],
         "arch":"x86_64",
         "endian":"little",
         "env":"msvc",
         "family":"windows",
         "features":["fxsr","sse","sse2"],
         "os":"windows",
         "pointer_width":"64",
         "vendor":"pc"
     },
     "targets": {
         "x86_64-unknown-linux-gnu": {
             "names": ["debug_assertions", "unix"],
             "arch":"x86_64",
             "endian":"little",
             "env":"gnu",
             "family":"unix",
             "features": ["fxsr","sse","sse2"],
             "os":"linux",
             "pointer_width":"64",
             "vendor":"unknown"
         },
         "i686-pc-windows-msvc": {
             "names": ["windows", "debug_assertions"],
             "arch":"x86",
             "endian":"little",
             "env":"msvc",
             "family":"windows",
             "features":["fxsr","sse","sse2"],
             "os":"windows",
             "pointer_width":"32",
             "vendor":"pc"
         }
     }
 }
```

I decided to remove the "target_" prefix from the relevant configurations to reduce "noise" in the output. Again, I am open to alternatives or suggestions on the JSON format.

Auto merge of #9105 - Swatinem:rustdoc-run-cwd, r=alexcrichton

Run rustdoc doctests relative to the workspace

By doing so, rustdoc will also emit workspace-relative filenames for the doctests.

This was first landed in #8954 but later backed out in #8996 because it changed the CWD of rustdoc test invocations.

The second try relies on the new `--test-run-directory` rustdoc option which was added in https://github.com/rust-lang/rust/pull/81264 to explicitly control the rustdoc test cwd.

fixes #8993

Auto merge of #9175 - wickerwaka:env-section, r=alexcrichton

Add support for [env] section in .cargo/config.toml

This adds support for an `[env]` section in the config.toml files. Environment variables set in this section will be applied to the environment of any processes executed by cargo.

This is implemented to follow the recommendations in https://github.com/rust-lang/cargo/pull/8839#issuecomment-725678657

Variables have optional `force` and `relative` flags. `force` means the variable can override an existing environment variable. `relative` means the variable represents a path relative to the location of the directory that contains the `.cargo/` directory that contains the `config.toml` file. A relative variable will have an absolute path prepended to it before setting it in the environment.

```
[env]
FOOBAR = "Apple"
PATH_TO_SOME_TOOL = { value = "bin/tool", relative = true }
USERNAME = { value = "test_user", force = true }
```

Fixes #4121

Run rustdoc doctests relative to the workspace

By doing so, rustdoc will also emit workspace-relative filenames for the doctests.

This was first landed in #8954 but later backed out in #8996 because it changed the CWD of rustdoc test invocations.

The second try relies on the new `--test-run-directory` rustdoc option which was added in https://github.com/rust-lang/rust/pull/81264 to explicitly control the rustdoc test cwd.

fixes #8993

Auto merge of #9161 - ehuss:index-v-features2, r=alexcrichton

Add schema field and `features2` to the index.

This adds a `v` field to the index which indicates a format version for an index entry. If Cargo encounters a version newer than it understands, it will ignore those entries. This makes it safer to make changes to the index entries (such as adding new things), and not need to worry about how older cargos will react to it. In particular, this will make it safer to run `cargo update` on older versions if we ever decide to add new things to the index.

Currently this is not written anywhere, and is intended as a safety guard for the future. For now I will leave it undocumented until we actually decide to start using it.

This also moves the new syntax for namespaced features and weak dependency features into a new field ("features2") in the index. This is necessary to avoid breaking Cargo versions older than 1.19, which fail to parse the index even if there is a Cargo.lock file.

It is intended that only crates.io will bother with creating this field. Other registries don't need to bother, since they generally don't support Cargo older than 1.19.

I'm uncertain exactly when we should try to update crates.io to start accepting this, as that is a somewhat permanent decision.

Fix usage of assert methods

The `with_stdout_contains` was mis-used. Since some lines may or may not
appear for some compiler targets and environments (nightly, beta,
stable, etc.) the tests would fail because the output was not identical.
Instead of a using raw strings, each line with the arch, endian, env,
family, vendor, pointer_width, etc. that are known to always be
present (at least of the CI builds) are included. This should work for
the CI environments and my local environment.

Fix tests for CI environment

The `panic="unwind"` appears in the output for the CI tests, but not in
my local tests. I need to investigate the origin of this configuration
but it causes the CI builds to fail.

Fix formatting

Add test with cargo configuration file

A `.cargo/config.toml` file is used to add the "crt-static" target
feature and test printing the compiler target configuration contains the
`target_feature="crt-static"` line.

Add test using RUSTFLAGS env var

The `RUSTFLAGS` environment variable is used to add the "crt-static"
target feature and test printing the target compiler configuration
contains the `target_feature="crt-static"` line.

Add multitarget test

Using the multitarget feature to print the configuration of multiple
compiler target configurations, a test is created.

Add first test

Not sure how to handle running the test on different hosts, so the first
test is explicit about the compile target to print the configuration.

fix test suite

Make it more clear which module is being tested when running cargo test

Change env section parsing

`untagged` enum variants are not recognised by serde if the variant contains a `Value<T>` type.
This change uses an transparent "inner" enum `Value<T>` member, which is handled correctly by serde.

Auto merge of #9189 - weihanglo:issue-9137, r=ehuss

Document the default location where cargo install emitting build artifacts

Resolves #9137

Document the default location where `cargo install` emitting build artifacts.

Fix warning with unused import

Change to forwarding rustc stdio to cargo

The `exec_with_output` function and subsequent writing to stdout and
stderr is replaced with the `exec` function that inherits the stdio
streams from Cargo is used.

Weirdly, I originally tried to use the `exec` function but I go no
output. The `cargo run -- rustc --print cfg` appear to just hang. So, I
switched to using the `exec_with_output` function. Now, the `exec`
function appears to work and it is much simplier. There must have been
something else going on with my system at the time.

Fix index_v version check.

The whole point is that when loading a cache from an earlier version,
that cache may be missing new entries. So don't load older caches.

doc: generated by build-man.sh

doc(man): clarify `--path` influnce on `target-dir`

Change how workspace resolve behavior is calculated.

This fixes an issue where warnings would be printed for packages
migrating to 2021 in a workspace (that the "resolver" field is ignored,
which is wrong).

This also places the default resolver logic in one place, and should
make it easier to update later.

`cargo fix`: Remove --prepare-for option.

This was deprecated, never officially part of the stable release.

Add some more details to the `cargo fix --edition` procedure.

Make edition transitions easier.

This attempts to centralize all the edition stuff in one place (the
`Edition` enum) so that adding a new edition or stabilizing one should
be relatively little work (and more importantly, we don't miss things).

Importantly, this changes `cargo new` to default to the latest stable.
It also changes the `cargo fix --edition-idiom` behavior to only apply
idioms for the *current* edition.

Include the index version in the index cache.

This is intended to help prevent the following scenario from happening:

1. Old cargo builds an index cache.
2. Old cargo finds an index entry it cannot parse, skipping it,
   and saving the cache without the entry.
3. New cargo loads the cache with the missing entry, and never sees
   the new entries that it understands.

This may result in more cache thrashing, but that seems better than
having new cargos missing entries.

Auto merge of #9185 - horacimacias:master, r=ehuss

Do not exit prematurely if anything failed installing.

https://github.com/rust-lang/cargo/issues/9180

doc: generated by build-man.sh

doc(man): add temp-target-dir variable

Do not exit prematurely if anything failed installing.
https://github.com/rust-lang/cargo/issues/9180

Auto merge of #9182 - alexcrichton:fix-lto-off, r=ehuss

Propagate `lto=off` harder

This commit fixes an issue with LTO calculation for various units when
`lto=off` is specified in the profile. This ensures now that `lto=off`
is passed to all transitive dependencies as well to disable thin-local
LTO. As an added bonus this also passed `embed-bitcode=no` whenever
`lto=off` is specified since we know we won't be using bitcode anyway.

Closes #9171

Auto merge of #9183 - weihanglo:refactor/straighforward-deref, r=alexcrichton

refactor: make deref intentions more straightforward

Just some little tweaks to make intentions of deref more straightforward.

Do not exit prematurely if anything failed installing.
https://github.com/rust-lang/cargo/issues/9180

Update `cargo fix --edition` docs.

# Conflicts:
# src/cargo/ops/fix.rs
# src/doc/src/reference/unstable.md

Updates to `cargo fix --edition`.

* `--edition` always means "next" edition.
* `--edition` when on the most recent edition is not an error, just a warning.
* Support fix to 2021 edition.