refactor(add): Pull UI concerns out of edit logic

refactor(add): Consolidate looking up available features

This optimization doesn't really make a difference and it makes it
harder to separate UI / edit concerns.

refactor(add): Decouple available features from inheritance

style(add): Clean up Context import

Auto merge of #11023 - dpc:cargo-cmd-path-order, r=epage

Do not add home bin path to PATH if it's already there

This is to allow users to control the order via PATH if they so desire.

Tested by preparing two different `cargo-foo` scripts in `$HOME/.cargo/bin` and `$HOME/bin`:

```
> env PATH="/usr/bin/:$HOME/bin:$HOME/.cargo/bin" ./target/debug/cargo foo
Inside ~/bin/
> env PATH="$HOME/.cargo/bin:/usr/bin/:$HOME/bin" ./target/debug/cargo foo
Inside ~/.cargo/bin/
> env PATH="/usr/bin/:$HOME/bin" ./target/debug/cargo foo
Inside ~/.cargo/bin/
```

and trailing slash:

```
> env PATH="$HOME/.cargo/bin/:/usr/bin/:$HOME/bin" ./target/debug/cargo foo
Inside ~/.cargo/bin/
> env PATH="/usr/bin/:$HOME/bin:$HOME/.cargo/bin/" ./target/debug/cargo foo
Inside ~/bin/
```

Fix https://github.com/rust-lang/cargo/issues/11020

Auto merge of #11081 - WaffleLapkin:no_for_in_option, r=epage

Don't use `for` loop on an `Option`

This PR removes a single `for` loop over `Option`, replacing it with an `if let` to improve code clarity. This currently blocks https://github.com/rust-lang/rust/pull/99696 that adds a lint against this pattern.

Auto merge of #11080 - hi-rustin:rustin-patch-dead-code, r=epage

Remove dead code

### What does this PR try to resolve?

Remove the dead code. I found it when I tried to build cargo.

r? `@epage`

Don't use `for` loop on an `Option`

Remove dead code

Signed-off-by: hi-rustin <rustin.liu@gmail.com>

Auto merge of #11068 - arlosi:progress, r=epage

Change progress indicator for sparse registries

The progress indicator for sparse registries previously could go backwards as new dependencies are discovered, which confused users.

The new indicator looks like this:
```
    Updating crates.io index
       Fetch [====================>            ] 46 complete; 29 pending
```

The progress bar percentage is based the current depth in the dependency tree, with a hard coded limit at `10/11`. This provides natural feeling progress for many projects that I tested.

`complete` represents the number of index files downloaded, `pending` represents the number of index files that Cargo knows need to be downloaded but have not yet finished.

Fixes #10820

Change progress indicator for sparse registries

It's now based on an estimate of the depth of the dependency tree, so the progress bar
will never go backwards.

Auto merge of #11055 - epage:docs, r=ehuss

chore(ci): Ensure intradoc links are valid

The plan is to move the architecture documents over to rustdoc so they can more easily stay up-to-date.  To do so, we'll need to enforce that the intradoc links stay valid.

As part of this, the PR run for `cargo doc` was updated to the command in #11019

Do not add home bin path to PATH if it's already there

This is to allow users to control the order via PATH if they so desire.

Fix #11020

Auto merge of #11044 - Eh2406:file_hash, r=weihanglo

Cache index files based on contents hash

Since #10507 Cargo has known how to read registry cached files whose index version starts with the hash of the file contents. Git makes it very cheap to determine the hash of a file. This PR switches cargo to start writing the new format.

Cargoes from before #10507 will not know how to read, and therefore overwrite, cached files written by Cargos after this PR.

Cargos after this PR can still read, and will consider up-to-date cached files written by all older Cargos.

As I'm writing this out I'm thinking that there may not be any point in writing a file that has both. An alternative implementation just writes the file contents hash. 🤔

Auto merge of #11051 - EstebanBorai:fix/specify-crate-name-maxlength, r=weihanglo

fix: specifies the max length for crate name

Provides the maximum length on the crate name as is defined
in the [crate's validation source code from crates.io][1].

[1]: https://github.com/rust-lang/crates.io/blob/3fc08ba57e782cff422a2f92503f09287d1a5140/src/models/krate.rs#L74

chore(ci): Ensure intradoc links are valid

fix: remove wrapping for sentence

fix: add periods to list items

Co-authored-by: Weihang Lo <weihanglo@users.noreply.github.com>

fix: list under restrictions

fix: specifies the max length for crate name

Provides the maximum length on the crate name as is defined
in the [crate's validation source code from crates.io][1].

[1]: https://github.com/rust-lang/crates.io/blob/3fc08ba57e782cff422a2f92503f09287d1a5140/src/models/krate.rs#L74

only wright contents hash

Auto merge of #10511 - weihanglo:issue-10477, r=ehuss

Support inheriting jobserver fd for external subcommands

Cache based on contents hash

Auto merge of #11029 - epage:config, r=weihanglo

refactor(cli): Lazy load config

This is trying to clarify `-C` support when it is implemented in #10952

Cargo currently has two initialization states for Config, `Config::default` (process start) and `config.configure` (after parsing args).  The most help we provide for a developer touching this code is a giant `CAUTION` comment in one of the relevant functions.

Currently, #10952 adds another configuration state in the middle where the `current_dir` has been set.

The goal of this PR is to remove that third configuration state by
- Lazy loading `Config::default` so it can be called after parsing `-C`
- Allowing `-C` support to assert that the config isn't loaded yet to catch bugs with it

The hope is this will make the intent of the code clearer and reduce the chance for bugs.

In doing this, there are two intermediate refactorings
- Make help behave like other subcommands
  - Before, we had hacks to intercept raw arguments and to intercept clap errors and assume what their intention was to be able to implement our help system.
  - This flips it around and makes help like any other subcommand,
simplifying cargo initialization.
  - We had to upgrade clap because this exposed a bug where `Command::print_help` wasn't respecting `disable_colored_help(true)`
- Delay fix's access to config

Personally, I also find both changes make the intent of the code clearer.

To review this, I recommend looking at the individual commits.   As this is just refactors, this has no impact on testing.

refactor(cli): Lazily do first-pass config loading

This will be a help for cases like #10952 which I would expect would
assert that the config is not loaded before changing the current_dir.

refactor(cli): Delay fix's access to config

My hope is to make it so we can lazy load the config.  This makes it so
we only load the config for the fix proxy if needed.

I also feel like this better clarifies the intention of the code that we
are running in a special mode.

refactor(cli): Make help behave like other subcommands

Before, we had hacks to intercept raw arguments and to intercept clap
errors and assume what their intention was to be able to implement our
help system.

This flips it around and makes help like any other subcommand,
simplifying cargo initialization.

Auto merge of #11040 - epage:confusion, r=ehuss

chore: Don't show genned docs in ripgrep

The goal is to help new (and existing) users more quickly find the
appropriate files to edit (like in #11033).  The main downside is for
someone trying to find output to verify what it looks like, a simple
search won't turn up results but there are other ways around that
(`--no-ignore`, `git status` after doing a man generation, etc).

Auto merge of #11019 - weihanglo:doc-private-items-cargo-itself, r=epage

Document private items for Cargo and publish under contributor guide

Auto merge of #11039 - ehuss:ci-names, r=epage

Add names to CI jobs

This adds names to the CI jobs. I've often found the existing auto-generated names to be confusing, and I think it would help to make them a little more succinct and clearer.

Before:
<img width="314" alt="image" src="https://user-images.githubusercontent.com/43198/187777515-6237f765-d747-4d74-8e06-baa86fbe8b2f.png">

After:
<img width="295" alt="image" src="https://user-images.githubusercontent.com/43198/187777559-6e21f08a-cf4c-4aaf-86ba-201bdd90c84f.png">

chore: Don't show genned docs in ripgrep

The goal is to help new (and existing) users more quickly find the
appropriate files to edit (like in #11033).  The main downside is for
someone trying to find output to verify what it looks like, a simple
search won't turn up results but there are other ways around that
(`--no-ignore`, `git status` after doing a man generation, etc).

Add names to CI jobs

Auto merge of #11028 - ehuss:test-errors, r=weihanglo

Rework test error handling

This reworks how errors are handled when running tests and benchmarks. There were some cases where Cargo was eating the actual error and not displaying it. For example, if a test process fails to launch, it only displayed the `could not execute process` message, but didn't explain why it failed to execute. This fixes it to ensure that the full error chain is displayed.

This also tries to simplify how the errors are handled, and makes them more uniform across `test` and `bench`, and with doctests.

This also changes the `--no-fail-fast` behavior to report errors as they happen instead of grouped at the end (and prints a summary at the end). This helps to make it clearer when a nonstandard error happens. For example, before:

```
     Running tests/t1.rs (target/debug/deps/t1-bb449dfa37379ba1)

running 1 test
     Running tests/t2.rs (target/debug/deps/t2-1770ae8367bc97ce)

running 1 test
test bar ... FAILED

failures:

---- bar stdout ----
thread 'bar' panicked at 'y', tests/t2.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

failures:
    bar

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

error: test failed.

Caused by:
  process didn't exit successfully: `/Users/eric/Temp/z12/target/debug/deps/t1-bb449dfa37379ba1` (signal: 11, SIGSEGV: invalid memory reference)
  process didn't exit successfully: `/Users/eric/Temp/z12/target/debug/deps/t2-1770ae8367bc97ce` (exit status: 101)
```

and the changes to that are:

```diff
`@@` -1,6 +1,10 `@@`
      Running tests/t1.rs (target/debug/deps/t1-bb449dfa37379ba1)

 running 1 test
+error: test failed, to rerun pass `--test t1`
+
+Caused by:
+  process didn't exit successfully: `/Users/eric/Temp/z12/target/debug/deps/t1-bb449dfa37379ba1` (signal: 11, SIGSEGV: invalid memory reference)
      Running tests/t2.rs (target/debug/deps/t2-1770ae8367bc97ce)

 running 1 test
`@@` -18,8 +22,7 `@@`

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

-error: test failed.
-
-Caused by:
-  process didn't exit successfully: `/Users/eric/Temp/z12/target/debug/deps/t1-bb449dfa37379ba1` (signal: 11, SIGSEGV: invalid memory reference)
-  process didn't exit successfully: `/Users/eric/Temp/z12/target/debug/deps/t2-1770ae8367bc97ce` (exit status: 101)
+error: test failed, to rerun pass `--test t2`
+error: 2 targets failed:
+    `--test t1`
+    `--test t2`
```

In the first example, when it says `Running tests/t1.rs`, there is no error message displayed until after all the tests finish, and that error message is not associated with the original test. This also includes the "to rerun" hint with `--no-fail-fast`.

Auto merge of #11033 - buggymcbugfix:buggymcbugfix/cargo-add-docs, r=epage

Very slight `cargo add` documentation improvements

As discussed in https://github.com/rust-lang/book/pull/3331, a quick explanation of the `Features` part of the message that gets printed to stdout when adding some dependency.

Consider the following example:

```
cargo add my-crate
    Updating crates.io index
      Adding my-crate v0.1.0 to dependencies.
             Features:
             + foo
             - bar
```

It was not clear to me what `+foo` and `-bar` meant until `@carols10cents'` kindly explained it to me. Hopefully the documentation now clarifies this.

TODO:

- [x] Run `./build-man.sh`

Document cargo-add's feature message

This refers to the `Features` part of the message that gets printed to
stderr after successfully adding some dependency, e.g.:

```
cargo add my-crate
    Updating crates.io index
      Adding my-crate v0.1.0 to dependencies.
             Features:
             + foo
             - bar
```

This tells us that the `foo` feature is enabled and `bar` is disabled.

Auto merge of #11030 - ehuss:update-installation-requirements, r=epage

Update compiling requirements.

This updates the requirements for building cargo itself. It adds a little more clarification on exactly what is needed, and what some of the options are.

This may be a little bit too much detail, as usually I suspect most users will just run `cargo build` and follow the error message instructions on what to install next.

Update compiling requirements.

Rework test error handling

Auto merge of #11027 - tshepang:patch-1, r=ehuss

doc: pause, for readability

pause, for readability

Auto merge of #11004 - jonhoo:bump-git2, r=weihanglo

Bump git2 to 0.15 and libgit2-sys to 0.14

This will allow cargo to avoid vendored builds of git2 in up-to-date
environments going forward, and brings in the [libgit2 1.4.4 CVE fix].

[libgit2 1.4.4 CVE fix]: https://github.com/libgit2/libgit2/releases/tag/v1.4.4

Auto merge of #11025 - hi-rustin:rustin-patch-typo, r=Eh2406

Fix typo

Just fix a typo. bacwkards -> backwards

Fix typo

Signed-off-by: hi-rustin <rustin.liu@gmail.com>

Auto merge of #11021 - 4TT1L4:patch-1, r=weihanglo

Update cargo-toml-vs-cargo-lock.md

 - Improved wording ('rev' is not a line)

Update cargo-toml-vs-cargo-lock.md

 - Improved wording ('rev' is not a line)

Make CI build API doc

Add rustdoc for lib.rs

Fix rustdoc warnings when documenting private items

Auto merge of #10807 - dtolnay-contrib:sha256, r=weihanglo

Apply GitHub fast path even for partial hashes

### What does this PR try to resolve?

As flagged in https://github.com/rust-lang/cargo/pull/10079#issuecomment-1170940132, it's not great to assume that git SHAs would always be 40-character hex strings. In the future they will be longer.

> Git is on a long-term trajectory to move to SHA256 hashes ([current status](https://lwn.net/SubscriberLink/898522/f267d0e9b4fe9983/)). I suppose when that becomes available/the default it's possible for a 40-digit hex-encoded hash not to be the full hash. Will this fail for that case?

The implementation from #10079 fails in that situation because it turns dependencies of the form `{ git = "…", rev = "[…40 hex…]" }` into fetches with a refspec `+[…40 hex…]:refs/commit/[…40 hex…]`. That only works if the 40 hex digits are the *full* long hash of your commit. If it's really a prefix ("short hash") of a 64-hex-digit SHA-256 commit hash, you'd get a failure that resembles:

```console
error: failed to get `dependency` as a dependency of package `repro v0.0.0`

Caused by:
  failed to load source for dependency `dependency`

Caused by:
  Unable to update https://github.com/rust-lang/dependency?rev=b30694b4d9b29141298870b7993e9aee10940524

Caused by:
  revspec 'b30694b4d9b29141298870b7993e9aee10940524' not found; class=Reference (4); code=NotFound (-3)
```

This PR updates the implementation so that Cargo will curl GitHub to get a resolved long commit hash *even if* the `rev` specified for the git dependency in Cargo.toml already looks like a SHA-1 long hash.

### Performance considerations

⛔ This reverses a (questionable, negligible) benefit of #10079 of skipping the curl when `rev` is a long hash and is not already present in the local clone. These curls take 200-250ms on my machine.

🟰 We retain the much larger benefit of #10079 which comes from being able to precisely fetch a single `rev`, instead of fetching all branches and tags in the upstream repo and hoping to find the rev somewhere in there. This accounts for the entire performance difference explained in the summary of that PR.

🟰 We still skip the curl when `rev` is a **long hash** of a commit that is already previously fetched.

🥳 After this PR, we also curl and hit fast path when `rev` is a **short hash** of some upstream commit. For example `{ git = "https://github.com/rust-lang/cargo", rev = "b30694b4d9" }` would previously have done the download-all-branches-and-tags codepath because `b30694b4d9` is not a long hash. After this PR, the curl to GitHub informs us that `b30694b4d9` resolves to the long hash `b30694b4d9b29141298870b7993e9aee10940524`, and we download just that commit instead of all-branches-and-tags.

### How should we test and review this PR?

I tested with the following dependency specs, using `/path/to/target/release/cargo generate-lockfile`.

```toml
# Before: slow path (fetch all branches and tags; 70K git objects)
# After: fast path (20K git objects)
cargo = { git = "https://github.com/rust-lang/cargo", rev = "b30694b4d9b2914129" }
```

```toml
# Before and after: fast path
cargo = { git = "https://github.com/rust-lang/cargo", rev = "b30694b4d9b29141298870b7993e9aee10940524" }
```

```toml
# Before and after: fast path
cargo = { git = "https://github.com/rust-lang/cargo", rev = "refs/heads/rust-1.14.0" }
```

```toml
# Before and after: same error "revspec 'rust-1.14.0' not found"
# You are supposed to use `branch = "rust-1.14.0"`, this is not considered a `rev`
cargo = { git = "https://github.com/rust-lang/cargo", rev = "rust-1.14.0" }
```

I made sure these all work both with and without `rm -rf ~/.cargo/git/db/cargo-* ~/.cargo/git/checkouts/cargo-*` in between each cargo invocation.

FYI `@djc`

Auto merge of #11017 - BlackHoleFox:non-ascii-names, r=weihanglo

Update non-ASCII crate name warning message

This PR fixes an outdated warning when initializing crates sometimes.

### What does this PR try to resolve?
Per [a Zulip convo](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Non-ASCII.20crate.20name.20status/near/294876491) on the topic, non-ASCII crate names are no longer allowed on any toolchain since https://github.com/rust-lang/rust/pull/73305, during the `non_ascii_idents` feature's development. Cargo however tells the user that they are accepted on Nightly. Rust and Cargo should agree on this point to avoid future confusion.

### How should we test and review this PR?
This should be covered by the existing test that was changed but if desired its easy to test with a checkout:

```
Running `/Users/fox/x/Forks/cargo/target/release/cargo init 'ああああ'`
warning: the name `ああああ` contains non-ASCII characters
Non-ASCII crate names are not supported by Rust.
```

Update non-ASCII crate name warning message

Auto merge of #11011 - hi-rustin:rustin-patch-tests, r=epage

Add more tests for aggressive or precise update

### What does this PR try to resolve?

When I was working on https://github.com/rust-lang/cargo/pull/10988, I found there is no test for the aggressive update. So I added it.

Also, I added a test for precise update to make sure it won't force update the deps of SPEC.
### How should we test and review this PR?

Unit tests.

Remove useless log deps and add more test for precise update

Signed-off-by: hi-rustin <rustin.liu@gmail.com>

Add test for aggressive update

Signed-off-by: hi-rustin <rustin.liu@gmail.com>

Auto merge of #11008 - weihanglo:issue-10917, r=epage

Ignore broken but excluded file during traversing

Ignore broken but excluded file during traversing

Walkdir's [`filter_entry()`][1] won't call the predicate if the entry
is essentially an `Err` from its underyling `IntoIter`. That means
Cargo hasn't had a chance to call `filter` on an entry that should be
excluded but eventually return an `Err` and cause the loop to stop.
For instance, a broken symlink which should bee excluded by `filter`
will generate an error since `filter` closure is not called with it.

The solution is calling `filter` if an error occurs with a path
(because it has yet been called with that path).
If it's exactly excluded, ignore the error.

[1]: https://github.com/BurntSushi/walkdir/blob/abf3a15887758e0af54ebca827c7b6f8b311cb45/src/lib.rs#L1042-L1058

test: ignore broken but excluded file during traversing

Remove unnecessary mutability

Auto merge of #10999 - hi-rustin:rustin-patch-wrong-names, r=epage

Improve error message for wrong target names

### What does this PR try to resolve?

Fixes https://github.com/rust-lang/cargo/issues/10982

We can print all available targets for users.

### How should we test and review this PR?

- [x] unit test

Update old tests

Signed-off-by: hi-rustin <rustin.liu@gmail.com>

Improve error message for wrong target names

Auto merge of #11005 - jonhoo:bump-snapbox, r=epage

Bump snapbox to 0.3

0.3 has a small number of [breaking changes], but makes diffs much
easier to visually parse by eliding large sections of unchanged content.

[breaking changes]: https://github.com/assert-rs/trycmd/blob/main/crates/snapbox/CHANGELOG.md#030---2022-08-01

r? `@epage`

Disable owner validation for Cargo-as-a-binary

Bump snapbox to 0.3

0.3 has a small number of [breaking changes], but makes diffs much
easier to visually parse by eliding large sections of unchanged content.

[breaking changes]: https://github.com/assert-rs/trycmd/blob/main/crates/snapbox/CHANGELOG.md#030---2022-08-01

Bump git2 to 0.15 and libgit2-sys to 0.14

This will allow cargo to avoid vendored builds of git2 in up-to-date
environments going forward, and brings in the [libgit2 1.4.4 CVE fix].

[libgit2 1.4.4 CVE fix]: https://github.com/libgit2/libgit2/releases/tag/v1.4.4

Auto merge of #11001 - Muscraft:fix-unstable-docs, r=weihanglo

remove missed reference to workspace inheritance in unstable.md

Currently on the nightly docs, workspace inheritance is [under the  stable table](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#workspace-inheritance-1)  and the [unstable table](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#workspace-inheritance). It looks like I forgot to remove it from the unstable table when working on stabilization.

I am not sure if it is worth a beta backport but I will happily open a PR for it if needed.

remove missed reference to workspace inheritance in unstable.md

Auto merge of #10988 - hi-rustin:rustin-patch-warn, r=epage

Warning when precise or aggressive without -p flag

### What does this PR try to resolve?

ref https://github.com/rust-lang/cargo/issues/10919.

Warning when precise or aggressive without -p flag. It will be a hard error in future.

### How should we test and review this PR?

- Unit test.

Add test for aggressive update

Signed-off-by: hi-rustin <rustin.liu@gmail.com>

Warning when precise or aggressive  without -p flag

Signed-off-by: hi-rustin <rustin.liu@gmail.com>

Auto merge of #10944 - kcrimson-ar:master, r=epage

Improve error message for an array value in the manifest

Fixes https://github.com/rust-lang/cargo/issues/10942

The error message will be:

```
error: failed to parse manifest at `/Users/..`

Caused by:
  invalid type: string "Ky", expected an array for key `package.authors`
```

Auto merge of #10975 - theCapypara:flock-enosys-android, r=weihanglo

Fix file locking being not supported on Android raising an error

This PR fixes #10972 by not failing Cargo operations when the `target_os` is Android and file locking is being reported as not being implemented by the kernel.

I am sadly unable to actually test this at the moment, since despite my best efforts I am not able to get Cargo actually cross-compiled for Android (aarch64-linux-android).

I however don't see any reason why this wouldn't work. `target_os` is "android" on Android and not "linux".

No longer gate unsupported file locking behind Linux as OS

Auto merge of #10983 - ehuss:version-bump, r=weihanglo

Bump to 0.66.0, update changelog

Also mention `build.target` being an array.

Update changelog for 1.64

Bump to 0.66.0

Auto merge of #10977 - weihanglo:std-thread-scope, r=epage

Use `std::thread::scope` to replace crossbeam

Drop one dependency as `std::thread::Scope` got stabilized in 1.63.

Haven't done any benchmark. (Should we?)

Auto merge of #10978 - andrewpollack:docs-removing-excess-in, r=weihanglo

[docs] Remove extra "in" from `cargo-test.md`

Removes an extra "in" from doc src/doc/src/commands/cargo-test.md

Successor to #10971 without bungled merge

Removing excess in

Use std::thread::scope to replace crossbeam

Auto merge of #10930 - ehuss:enable-windows-tests, r=weihanglo

Enable two windows tests

These two tests were disabled on Windows a long time ago. AFAICT, the reasons are no longer relevant, and it should be safe to enable these tests. See each commit for a more detailed exposition.

Fix flock being not supported on Android raising an error

Auto merge of #10968 - hi-rustin:rustin-patch-msg, r=ehuss

Improve error msg for get target runner

Actually, we'll get this config from three places. So this msg may be confusing when you set it up in `.cargo/config.toml` or pass it by `--config`.
We already printed the location of the config, so I think it's OK to change it to `configurations`.

Auto merge of #10962 - Nemo157:override-target-dir, r=ehuss

Ensure rustc-echo-wrapper works with an overridden build.target-dir

Without this when running with an overridden target-dir there are about a dozen test failures like

```console
> mkdir .cargo
> echo '[build]\ntarget-dir = "not-target"' > .cargo/config
> cargo test -- fix::does_not_crash
---- fix::does_not_crash_with_rustc_wrapper stdout ----
running `/home/nemo157/sources/cargo/not-target/debug/cargo build`
running `/home/nemo157/sources/cargo/not-target/debug/cargo fix --allow-no-vcs`
thread 'fix::does_not_crash_with_rustc_wrapper' panicked at '
test failed running `/home/nemo157/sources/cargo/not-target/debug/cargo fix --allow-no-vcs`
error: process exited with code 101 (expected 0)
--- stdout

--- stderr
error: failed to run `rustc` to learn about target-specific information

Caused by:
  could not execute process `/home/nemo157/sources/cargo/not-target/tmp/cit/rustc-echo-wrapper/target/debug/rustc-echo-wrapper rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (never executed)

Caused by:
  No such file or directory (os error 2)
', tests/testsuite/fix.rs:1228:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

Because the `rustc-echo-wrapper` is compiled to `not-target/debug/rustc-echo-wrapper`.

This is resolved by forcing the target-dir to be a manifest-relative one for this specific build.

Auto merge of #10969 - joshtriplett:available-parallelism, r=epage

Switch back to `available_parallelism`

This reverts commit 8345cf5037506b38457483429fb113322c58f668 now that https://github.com/rust-lang/rust/pull/97925 is merged.

Since that
time, there are now multiple calls to get the number of CPUs, to handle
the `-j -NUM` case, so factor out a helper function.

Switch back to `available_parallelism`

This reverts commit 8345cf5037506b38457483429fb113322c58f668. Since that
time, there are now multiple calls to get the number of CPUs, to handle
the `-j -NUM` case, so factor out a helper function.

Ensure rustc-echo-wrapper works with an overridden build.target-dir

Fix test

Signed-off-by: hi-rustin <rustin.liu@gmail.com>

Improve error msg for get target runner

Signed-off-by: hi-rustin <rustin.liu@gmail.com>

Auto merge of #10961 - Nemo157:skip-implicit-override, r=epage

Only override published resolver when the workspace is different

### What does this PR try to resolve?

Ensures when publishing a package that uses an implicit `resolver = "1"` to maintain an MSRV before the `resolver` key was stabilized the implicitness is retained rather than being turned into an explicit setting.

fixes #10954 (assuming that the workspace and its packages are configured with a consistent resolver)

Auto merge of #10967 - hi-rustin:rustin-patch-docs, r=epage

Add `CARGO_LOG` to "Environment variables Cargo reads"

### What does this PR try to resolve?
close https://github.com/rust-lang/cargo/issues/10947

Add `CARGO_LOG` to `Environment variables Cargo reads`

Signed-off-by: hi-rustin <rustin.liu@gmail.com>

Only override published resolver when the workspace is different

Auto merge of #10891 - joshtriplett:rust-version-recommend-precise, r=ehuss

Make the `rust-version` error recommend `cargo update --precise -p crate@ver`

People encountering a dependency with a newer `rust-version` requirement
may not know about `cargo update --precise`, or may consider alternate
approaches that may be harmful (such as pinning with a `=` dependency).

Provide specific guidance in the error message.

Have `Edition` know what its default resolver behaviour is

Only show advice to use `cargo update --precise` for non-local packages

Packages in the local workspace can't get updated this way; the user
just needs to point to a different source, or otherwise update the
package themselves.

Make the `rust-version` error recommend `cargo update -p crate@ver --precise ...`

People encountering a dependency with a newer `rust-version` requirement
may not know about `cargo update --precise`, or may consider alternate
approaches that may be harmful (such as pinning with a `=` dependency).

Provide specific guidance in the error message.

If the user is using `cargo install`, suggest `cargo install --locked` instead.

Add unit test for invalid authors, refactor name

Auto merge of #10946 - RalfJung:docs, r=epage

resolver docs: link to version requirements syntax full explanation

Staring at https://doc.rust-lang.org/cargo/reference/resolver.html#semver-compatibility, I was confused was this is a "refresher" for. Let's add a link to the main documentation this summarizes.