Mention `[patch]` config in "Overriding Dependencies"

Auto merge of #10831 - arlosi:sparse-publish-fix, r=Eh2406

Fix publishing to crates.io with -Z sparse-registry

Attempting to publish a crate to crates.io with `-Z sparse-registry` failed with the following error:

```
error: failed to publish to registry at https://crates.io

Caused by:
  the remote server responded with an error: Dependency `serde` is hosted on another registry. Cross-registry dependencies are not permitted on crates.io.
```

The check in `registry.rs` `dep_registry_id != registry_id` caused the `publish` operation include the crates.io index url in the HTTP request because the id was replaced. The crates.io API seems to require that the `registry` field is not present.

This change fixes the issue by making the `registry` function return the non-replaced crates.io `source_id` only for this case. Other replacement indices of crates.io continue to include the registry URL when publishing.

Tested manually by publishing `arlosi-cargo-test` to crates.io with `-Z sparse-registry`

Fixes #10828
r? `@Eh2406`

Auto merge of #10830 - arlosi:parallel_yank, r=Eh2406

Make `is_yanked` return `Poll<>`

The `is_yanked` check performed by `cargo install` and `cargo package` was running sequentially (calling `block_until_ready` after every check).

This change makes `is_yanked` return `Poll<>` and runs the check in parallel, which gives better performance for `cargo install --locked` and `cargo package` when using a sparse registry.

fixes #10821
r? `@ehuss`

Auto merge of #10829 - ehuss:corrupted-checkout, r=weihanglo

Fix corrupted git checkout recovery.

This fixes an issue where cargo would not recover from a corrupted git checkout correctly when using `net.git-fetch-with-cli`.

Git dependencies have two clones, the "db" and the "checkout". The "db" is shared amongst multiple checkout revisions from the same repository. The "checkout" is each individual revision. There was some code in `copy_to` which creates the "checkout" that tries to recover from an error. The "checkout" can be invalid if cargo was interrupted while cloning it, or if there is fs corruption. However, that code was failing when using the git CLI.  For reasons I did not dig into, the "db" does not have a HEAD ref, so that special-case fetch was failing with a `couldn't find remote ref HEAD` error from `git`.

This changes it so that if the "checkout" is invalid, it just gets blown away and a new clone is created (instead of calling `git fetch` from the "db").

I believe there is some long history for this `copy_to` code where it made more sense in the past. Previously, the "checkout" directories used the `GitReference` string as-is. So, for example, a branch would checkout into a directory with that branch name. At some point, it was changed so that each checkout uses a short hash of the actual revision.  Rebuilding the checkout made sense when it was possible for that checkout revision to change (like if new commits were pushed to a branch).  That recovery is no longer necessary since a checkout is only ever one revision.

Fixes #10826

Fix publishing to crates.io with -Z sparse-registry

Run the is_yanked check in parallel for better performance with -Z sparse-registry

Fix corrupted git checkout recovery.

Auto merge of #10776 - Muscraft:cache-workspace-discovery, r=weihanglo

add a cache for discovered workspace roots

## History
`@ehuss` [noticed that](https://github.com/rust-lang/cargo/pull/10736#discussion_r894071933) workspace inheritance caused a significant increase in startup times when using workspace inheritance. This brought up the creation of #10747.

When using a similar test setup [to the original](https://github.com/rust-lang/cargo/pull/10736#discussion_r894822022) I got
```
Benchmark 1: cd rust; ../../../target/release/cargo metadata
  Time (mean ± σ):     149.4 ms ±   3.8 ms    [User: 105.9 ms, System: 31.7 ms]
  Range (min … max):   144.2 ms … 162.2 ms    19 runs

Benchmark 2: cd rust-ws-inherit; ../../../target/release/cargo metadata
  Time (mean ± σ):     191.6 ms ±   1.4 ms    [User: 145.9 ms, System: 34.2 ms]
  Range (min … max):   188.8 ms … 193.9 ms    15 runs
```

This showed a large increase in time per cargo command when using workspace inheritance.

During the investigation of this issue, other [performance concerns were found and addressed](https://github.com/rust-lang/cargo/pull/10761). This resulted in a drop in time across the board but heavily favored workspace inheritance.
```
Benchmark 1: cd rust; ../../../target/release/cargo metadata
  Time (mean ± σ):     139.3 ms ±   1.7 ms    [User: 99.8 ms, System: 29.4 ms]
  Range (min … max):   137.1 ms … 144.5 ms    20 runs

Benchmark 2: cd rust-ws-inherit; ../../../target/release/cargo metadata
  Time (mean ± σ):     161.7 ms ±   1.4 ms    [User: 120.4 ms, System: 31.2 ms]
  Range (min … max):   158.0 ms … 164.6 ms    18 runs
```

## Performance after changes
`hyperfine --warmup 10 "cd rust; ../../../target/release/cargo metadata" "cd rust-ws-inherit; ../../../target/release/cargo metadata" --runs 40`
```
Benchmark 1: cd rust; ../../../target/release/cargo metadata
  Time (mean ± σ):     140.1 ms ±   1.5 ms    [User: 99.5 ms, System: 30.7 ms]
  Range (min … max):   137.4 ms … 144.0 ms    40 runs

Benchmark 2: cd rust-ws-inherit; ../../../target/release/cargo metadata
  Time (mean ± σ):     141.8 ms ±   1.6 ms    [User: 100.9 ms, System: 30.9 ms]
  Range (min … max):   138.4 ms … 145.4 ms    40 runs
```

[New Benchmark](https://github.com/rust-lang/cargo/pull/10754)
`cargo bench -- workspace_initialization/rust`
```
workspace_initialization/rust
    time:   [14.779 ms 14.880 ms 14.997 ms]
workspace_initialization/rust-ws-inherit
    time:   [16.235 ms 16.293 ms 16.359 ms]
```

## Changes Made
- [Pulled a commit](https://github.com/rust-lang/cargo/pull/10736/commits/bbd41a4dca8e001c8a45979c563293ef0a5c0d77) from `@ehuss` that deduplicated finding a workspace root to make the changes easier
- Added a cache in `Config` to hold found `WorkspaceRootConfig`s
  - This makes it so manifests should only be parsed once
- Made `WorkspaceRootConfig` get added to the cache when parsing a manifest

## Testing Steps
To check the new benchmark:
1. `cd benches/benchsuite`
2. `cargo bench -- workspace_initialization/rust`

Using `hyperfine`:
1. run `cargo build --release`
2. extract `rust` and `rust-ws-inherit` in `benches/workspaces`
3. cd `benches/workspaces`
4. Prime the target directory with a cache of `rustc` info. In `rust` and `rust-ws-inherit`, run: `cargo +nightly c -p linkchecker`. Otherwise it would be measuring `rustc` overhead.
4. run `hyperfine --warmup 10 "cd rust; ../../../target/release/cargo metadata" "cd rust-ws-inherit; ../../../target/release/cargo metadata" --runs 40`

closes #10747

add a cache for discovered workspace roots

Auto merge of #10818 - Byron:flyby-fixes, r=weihanglo

fix typo

Auto merge of #10817 - epage:fix, r=weihanglo

fix(add): Don't panic with `--offline`

For some reason, I defined my own `--offline` flag and it didn't get
updated with the global `--offline` flag, so it started failing.

The new test previously paniced and now it doesn't.

Fixes #10814

fix(add): Don't panic with `--offline`

For some reason, I defined my own `--offline` flag and it didn't get
updated with the global `--offline` flag, so it started failing.

Fixes #10814

Auto merge of #10816 - turrisxyz:Pinned-Dependencies-GitHub, r=epage

chore: Set permissions for GitHub actions

 Restrict the GitHub token permissions only to the required ones; this way, even if the attackers will succeed in compromising your workflow, they won’t be able to do much.

- Included permissions for the action. https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions

https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs

[Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)

Signed-off-by: naveen <172697+naveensrinivasan@users.noreply.github.com>

chore: Set permissions for GitHub actions

 Restrict the GitHub token permissions only to the required ones; this way, even if the attackers will succeed in compromising your workflow, they won’t be able to do much.

- Included permissions for the action. https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions

https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs

[Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)

Signed-off-by: naveen <172697+naveensrinivasan@users.noreply.github.com>

fix typo

Auto merge of #10812 - ehuss:version-bump, r=Eh2406

Bump to 0.65.0, update changelog

Update changelog for 1.63

Bump to 0.65.0

Auto merge of #10810 - Diomendius:bugfix-zsh-completions, r=weihanglo

Fix zsh completions for add and locate-project

Currently, trying to tab-complete either the `cargo add` or `cargo locate-project` subcommands results in output such as this:
```
cargo add _cargo:67: command not found: --default-features[enable the default features]
_cargo:68: command not found: --no-default-features[don't enable the default features]
_cargo:69: command not found: --optional[mark the dependency as optional]
```

This is because some line continuations are missing from `src/etc/_cargo`. This PR adds these line continuations.

This file gets packaged for Rust releases by https://github.com/rust-lang/rust/blob/acdcdfb61b7b472bfacbb8bb889bdf3204827f2e/src/bootstrap/dist.rs#L956 and Rustup ultimately places it in `~/.rustup/toolchains/*/share/zsh/site-functions/_cargo`. `rustup completions zsh cargo` outputs a script which sources this filepath.

The easier approach to testing this is probably to manually copy `_cargo` to its proper location under `~/.rustup`, assuming Rust is already installed via Rustup and Zsh completions for Cargo are already installed, but however you choose to install this, testing is as simple as observing that Zsh can correctly tab complete `cargo add` and `cargo locate-project`.

Fix zsh completions for add and locate-project

The zsh tab-completion script had missing line continuations which would
cause `command not found:` errors when trying to complete the
`cargo add` or `cargo locate-project` subcommands.

Auto merge of #10804 - ehuss:bump-cargo-util, r=joshtriplett

Bump cargo-util version.

#10546 made a semver-incompatible change to the API of `ProcessBuilder::get_args`. Unfortunately we did not catch that until it was published. This bumps the version of cargo-util to 0.2.1 to accommodate that change. Stable will get version 0.2.0 so that the changes on beta can be released as 0.2.1 in their own time.

cc #10803

Auto merge of #10802 - ehuss:update-os_info, r=epage

Update os_info

This updates os_info which has had a number of improvements for detecting more platforms.

Changelog: https://github.com/stanislav-tkach/os_info/blob/master/CHANGELOG.md
Changes: https://github.com/stanislav-tkach/os_info/compare/v3.0.7...v3.4.0

Fixes #10800

Bump cargo-util version.

Update os_info

Auto merge of #10799 - Urgau:check-cfg-fix-config-deserialization, r=ehuss

Fix deserialization of check-cfg in config.toml

When improving the check-cfg implementation in https://github.com/rust-lang/cargo/pull/10566 I changed the internal representation of `check_cfg` from multiple `bool` options to one `Option<(bool, bool, bool, bool)>` but I didn't realize until https://github.com/rust-lang/rust/issues/82450#issuecomment-1169836928 that the internal representation is actually somewhat public as it's used in the `[unstable]` in `.cargo/config.toml`.

And because TOML cannot represent tuples there is no way to set it from the `[unstable]` section. This PR fix this oversight by using a custom deserializer method similar to what was already done for `build-std`.

Auto merge of #10798 - scop:patch-1, r=ehuss

fix: bash complete `install --path` with dirs

`--path` takes a mandatory dir argument.

Add regression tests for check-cfg unstable config

Fix config deserilization of check-cfg

feat: bash complete `install --path` with dirs

Auto merge of #10079 - dtolnay-contrib:fetch, r=ehuss

Fetch GitHub commits by long hash more efficiently

Closes #10078.

**Tested with the following Cargo.toml:**

```toml
[package]
name = "repro"
version = "0.0.0"
edition = "2021"
publish = false

[dependencies]
cargo = { git = "https://github.com/rust-lang/cargo", rev = "b30694b4d9b29141298870b7993e9aee10940524" }
```

```console
$ rm -rf ~/.cargo/git/db/cargo-* ~/.cargo/git/checkouts/cargo-*
$ time $CARGO generate-lockfile
$ du -shc ~/.cargo/git/db/cargo-* ~/.cargo/git/checkouts/cargo-*
```

Using current cargo from the most recent nightly, the `generate-lockfile` command downloads 69704 git objects in 7.0 seconds, consuming 41 MB on disk.

Using cargo built from this PR by `cargo build --release`, the same command downloads 21481 objects in 2.2 seconds, consuming 17 MB on disk.

Once libgit2 is able to do shallow clones (https://github.com/libgit2/libgit2/issues/3058) this can be even more of a speedup. Using command-line git (which does not use libgit2) and `time git fetch --depth=1 https://github.com/rust-lang/cargo b30694b4d9b29141298870b7993e9aee10940524` indicates that it downloads just 262 objects in 1.1 seconds.

Auto merge of #10778 - epage:test, r=ehuss

refactor(test): Clarify asserts are for UI

In writing the contrib documentation for functional vs ui tests, I
realized that as we work to make snapbox work for the functional tests,
we'll need distinct `Assert` objects since we'll want to elide a lot
more content in functional tests.  I'm making room for this by
qualifying the existing asserts as being for "ui".

Auto merge of #10785 - ehuss:fix-dead_code-diag, r=Eh2406

Fix tests due to change in dead_code diagnostic.

https://github.com/rust-lang/rust/pull/97853 changed some diagnostics which is causing some tests to fail on the latest nightly.  This updates the tests to work on both stable and nightly.

Fix tests due to change in dead_code diagnostic.

Auto merge of #10755 - jonhoo:stabilize-config-cli, r=ehuss

Stabilize config-cli

This stabilizes the `--config` CLI argument as per [this FCP](https://github.com/rust-lang/cargo/issues/7722#issuecomment-1114369809).

It also makes the adjustment [suggested by `@ehuss](https://github.com/rust-lang/cargo/issues/7722#issuecomment-1098612205)` to allow stabilizing `--config path` without _also_ stabilizing [`config-include`](https://doc.rust-lang.org/cargo/reference/unstable.html#config-include).

I took a guess that this would land in 1.63 and put that in the tombstone entry in the unstable docs, but let me know if that's likely to be wrong.

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

Also, I think this should probably be tagged `relnotes`.

refactor(test): Clarify asserts are for UI

In writing the contrib documentation for functional vs ui tests, I
realized that as we work to make snapbox work for the functional tests,
we'll need distinct `Assert` objects since we'll want to elide a lot
more content in functional tests.  I'm making room for this by
qualifying the existing asserts as being for "ui".

Include --config in cargo help output

Don't refer to --config as unstable

Auto merge of #10767 - danilhendrasr:master, r=epage

Restrict duplicate deps warning only to published packages

Fixes #10752

Restrict duplicate deps warning only to published packages

Fetch GitHub commits by long hash more efficiently

Auto merge of #10746 - shkoo:nils/custom_target_path_cache, r=weihanglo

Use fingerprint_hash when computing fingerprints for custom targets

This makes it easier to get reproducible builds for custom targets.

Rework how workspace roots are discovered.

This centralizes the workspace discovery code into one location
`find_workspace_root_with_loader` so that it isn't duplicated.

Merge pull request #10761 from Muscraft/reduce-parsing

Add preloading for workspace packages in `resolve_with_previous`

Auto merge of #10772 - tshepang:patch-2, r=Eh2406

capitalise, for consistency

Don't use the full pathname of a custom target json in fingerprint hashes.

This makes it easier to get reproducible builds for custom targets.

Auto merge of #10774 - Muscraft:update-benchsuite-deps, r=Eh2406

remove unused dependency from benchsuite

In #10754 I added a new benchmark to the benchsuite. While figuring out the best way to add the new benchmark, I added `cargo-test-support` as a dependency. It appears I missed removing it before making the PR.

This PR removes `cargo-test-support` since it is not needed

Auto merge of #10758 - epage:docs, r=weihanglo

docs(contrib): Add documentation for ui tests

### What does this PR try to resolve?

This only adds information about snapshot testing using `snapbox` and
keeps the functional testing documentation focused on the existing
facilities.  We can updated this as our use of `snapbox` matures.

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

I did not generate and verify the HTML

In writing this, I did notice that we define
`cargo_test_support::compare::assert` but only use it for filesystem
asserts and not binary asserts.  We should probably add our own function
that wraps `snapbox::cmd::Command::cargo()` and passes in
`cargo_test_support::compare::assert`.  I've left that out of this PR to
keep things focused.

remove unused dependency from benchsuite

docs(contrib): Update API item links

capitalise, for consistency

Auto merge of #10769 - jonhoo:patch-1, r=Eh2406

Remove repeated word in in dep: error message

Remove repeated word in in dep: error message

Auto merge of #10754 - Muscraft:benchsuite, r=epage

Add a benchmark for workspace initialization

It [was suggested](https://github.com/rust-lang/cargo/pull/10736#discussion_r894822022) that a benchmark for workspace initialization should be added. This was suggested because there were issues with the performance of [workspace inheritance](https://github.com/rust-lang/cargo/issues/10747) as well as a general way to track the workspace initialization time across cargo changes

### Changes
- Moved common functions out of `resolve.rs` to a shared `lib.rs`
- Added a new struct to be used when creating a new benchmark
  -  This was done because `env!("CARGO_TARGET_TMPDIR")` would fail to compile when put inside of the new `lib.rs`
- Added a new workspace test for workspace inheritance
  - This new workspace does not have a repo that it was built from and if one needs to be made I can change that

Stabilize --config

FCP
https://github.com/rust-lang/cargo/issues/7722#issuecomment-1114369809

Closes #7722.

Allow --config path without config-include

As per
https://github.com/rust-lang/cargo/issues/7722#issuecomment-1098612205

add a bench for workspace initialization

 refactor parts of benchsuite/resolve.rs to a library, so it can be used by other benchmarks

Auto merge of #10764 - kornelski:clarify-http, r=Eh2406

Use specific terminology for sparse HTTP-based registry

Before the options is popularized, I'd like to take opportunity to give it a unique name used consistently. It's been called "http" registry, but that's a rather generic term, especially that existing git-based registry also uses HTTP as its transport.

New registry URLs use `sparse+https://` prefix, so calling it "sparse" registry seems more appropriate.

#9069

HTTP-based -> sparse

Co-authored-by: Arlo Siemsen <arkixml@gmail.com>

docs(contrib): Add documentation for ui tests

This only adds information about snapshot testing using `snapbox` and
keeps the functional testing documentation focused on the existing
facilities.  We can updated this as our use of `snapbox` matures.

In writing this, I did notice that we define
`cargo_test_support::compare::assert` but only use it for filesystem
asserts and not binary asserts.  We should probably add our own function
that wraps `snapbox::cmd::Command::cargo()` and passes in
`cargo_test_support::compare::assert`.  I've left that out of this PR to
keep things focused.

Use specific terminology for sparse HTTP-based registry

Git-based registry uses HTTP too

add preloading for workspace packages in `resolve_with_previous` so manifests aren't parsed twice

Auto merge of #10753 - epage:clap32-deprecated, r=weihanglo

chore: Upgrade to clap 3.2

I decided to use cargo as a test case for upgrading to clap 3.2 prior to release.  From the builder API's perspective, a lot has change.  While the changelog summarizes it, the release announcement is still pending.  In short, the API is now typed.  You declare what type an `Arg` is and access it by that type.  flags (both `is_present` and `occurrences_of`) are also now specified through `ArgAction` and the result gets stored like any other arg value.  I made a `ArgMatchesExt::flag` and `command_prelude::flag` functions to make working with these easier.

Now that clap exposes non-panicking variants of its functions, I switched from a "look before you leap" approach with `is_arg_valid` to a "better to ask forgiveness than permission" with checking the error variant.  I decided to just make a convenience to swallow that error type.  Not a fan of how loose things are but I think this will just be something we iterate on over time.

refactor: Resolve clap 3.2 deprecations

chore: Upgrade to clap 3.2

refactor(cli): Centralize reading of verbose

Auto merge of #10738 - arlosi:auth-testingonly, r=ehuss

Improve testing framework for http registries

Improve integration of the http server introduced by the http-registry feature.

The same HTTP server is used for serving downloads, the index, and the API within the test framework.

This makes it easier to write tests that deal with authentication and http registries.

Most of this change is pulled from #10592. Getting it in separately should make the other change easier to review.

r? `@Eh2406`

Improve testing framework for http registries

Improve integration of the http server introduced by the http-registry feature.
Now the same HTTP server is used for serving downloads, the index, and
the API.

This makes it easier to write tests that deal with authentication and
http registries.

Auto merge of #10728 - jorendorff:patch-1, r=ehuss

doc: Improve example of using the links field

`"foo"` doesn't really help say what this is.

Auto merge of #10739 - weihanglo:revert-num-cpus, r=epage

Revert #10427: switch from num_cpus

Same as #10737 but on nightly

Revert #10427: switch from num_cpus

This reverts commit 6d11f9e7d4e8694b7a6a8465ec679ad422957078, reversing
changes made to c5cdd25c14ca7bd3f1691ed59535adb4f6b2c8df.

Auto merge of #10725 - arlosi:http-cratesio, r=Eh2406

Make -Z http-registry use index.crates.io when accessing crates-io

Use `sparse+https://index.crates.io/` to access crates.io when `-Z http-registry` is set.

* `Cargo.lock` files still emit the github URL `https://github.com/rust-lang/crates.io-index`.
* Allows publishing to a source-replaced `crates-io` only for `index.crates.io`. Other source-replacements of `crates-io` are still blocked.

Fixes #10722
r? `@Eh2406`

Make -Z http-registry use index.crates.io by default

Auto merge of #10717 - jsitnicki:respect-git-submod-update-none, r=epage

Respect submodule update=none strategy in .gitmodules

Git lets users define the default update/checkout strategy for a submodule
by setting the `submodule.<name>.update` key in `.gitmodules` file.

If the update strategy is `none`, the submodule will be skipped during
update. It will not be fetched and checked out:

1. *foo* is a big git repo

```
/tmp $ git init foo
Initialized empty Git repository in /tmp/foo/.git/
/tmp $ dd if=/dev/zero of=foo/big bs=1000M count=1
1+0 records in
1+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 0.482087 s, 2.2 GB/s
/tmp $ git -C foo add big
/tmp $ git -C foo commit -m 'I am big'
[main (root-commit) 84fb533] I am big
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 big
```

2. *bar* is a repo with a big submodule with `update=none`

```
/tmp $ git init bar
Initialized empty Git repository in /tmp/bar/.git/
/tmp $ git -C bar submodule add file:///tmp/foo foo
Cloning into '/tmp/bar/foo'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 1 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), 995.50 KiB | 338.00 KiB/s, done.
/tmp $ git -C bar config --file .gitmodules submodule.foo.update none
/tmp $ cat bar/.gitmodules
[submodule "foo"]
        path = foo
        url = file:///tmp/foo
        update = none
/tmp $ git -C bar commit --all -m 'I have a big submodule with update=none'
[main (root-commit) 6c355ea] I have a big submodule not updated by default
 2 files changed, 4 insertions(+)
 create mode 100644 .gitmodules
 create mode 160000 foo
```

3. *baz* is a clone of *bar*, notice *foo* submodule gets skipped

```
/tmp $ git clone --recurse-submodules file:///tmp/bar baz
Cloning into 'baz'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
Submodule 'foo' (file:///tmp/foo) registered for path 'foo'
Skipping submodule 'foo'
/tmp $ git -C baz submodule update --init
Skipping submodule 'foo'
/tmp $
```

Cargo, on the other hand, ignores the submodule update strategy set in
`.gitmodules` properties when updating dependencies. Such behavior can
be considered against the wish of the crate publisher.

4. *bar* is now a lib with a big submodule with update disabled

```
/tmp $ cargo init --lib bar
     Created library package
/tmp $ git -C bar add .
/tmp $ git -C bar commit -m 'I am a lib with a big submodule but update=none'
[main eb07cf7] I am a lib with a big submodule but update=none
 3 files changed, 18 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 Cargo.toml
 create mode 100644 src/lib.rs
/tmp $
```

5. *qux* depends on *bar*, notice *bar*'s submodules are fetched

```
/tmp $ cargo init qux && cd qux
     Created binary (application) package
/tmp/qux $ echo -e '[dependencies.bar]\ngit = "file:///tmp/bar"' >> Cargo.toml
/tmp/qux $ time cargo update
    Updating git repository `file:///tmp/bar`
    Updating git submodule `file:///tmp/foo`

real    0m22.182s
user    0m20.402s
sys     0m1.714s
/tmp/qux $
```

Fix it by checking if a Git repository submodule should be updated when
cargo processes dependencies.

6. With the change applied, submodules with `update=none` are skipped

```
/tmp/qux $ cargo cache -a > /dev/null
/tmp/qux $ time ~/src/cargo/target/debug/cargo update
    Updating git repository `file:///tmp/bar`
    Skipping git submodule `file:///tmp/foo`

real    0m0.029s
user    0m0.021s
sys     0m0.008s
/tmp/qux $
```

Fixes #4247.

Respect submodule update=none strategy in .gitmodules

Git lets users define the default update/checkout strategy for a submodule
by setting the `submodule.<name>.update` key in `.gitmodules` file.

If the update strategy is `none`, the submodule will be skipped during
update. It will not be fetched and checked out:

1. *foo* is a big git repo

```
/tmp $ git init foo
Initialized empty Git repository in /tmp/foo/.git/
/tmp $ dd if=/dev/zero of=foo/big bs=1000M count=1
1+0 records in
1+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 0.482087 s, 2.2 GB/s
/tmp $ git -C foo add big
/tmp $ git -C foo commit -m 'I am big'
[main (root-commit) 84fb533] I am big
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 big
```

2. *bar* is a repo with a big submodule with `update=none`

```
/tmp $ git init bar
Initialized empty Git repository in /tmp/bar/.git/
/tmp $ git -C bar submodule add file:///tmp/foo foo
Cloning into '/tmp/bar/foo'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 1 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), 995.50 KiB | 338.00 KiB/s, done.
/tmp $ git -C bar config --file .gitmodules submodule.foo.update none
/tmp $ cat bar/.gitmodules
[submodule "foo"]
        path = foo
        url = file:///tmp/foo
        update = none
/tmp $ git -C bar commit --all -m 'I have a big submodule with update=none'
[main (root-commit) 6c355ea] I have a big submodule not updated by default
 2 files changed, 4 insertions(+)
 create mode 100644 .gitmodules
 create mode 160000 foo
```

3. *baz* is a clone of *bar*, notice *foo* submodule gets skipped

```
/tmp $ git clone --recurse-submodules file:///tmp/bar baz
Cloning into 'baz'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
Submodule 'foo' (file:///tmp/foo) registered for path 'foo'
Skipping submodule 'foo'
/tmp $ git -C baz submodule update --init
Skipping submodule 'foo'
/tmp $
```

Cargo, on the other hand, ignores the submodule update strategy set in
`.gitmodules` properties when updating dependencies. Such behavior can
be considered against the wish of the crate publisher.

4. *bar* is now a lib with a big submodule with update disabled

```
/tmp $ cargo init --lib bar
     Created library package
/tmp $ git -C bar add .
/tmp $ git -C bar commit -m 'I am a lib with a big submodule but update=none'
[main eb07cf7] I am a lib with a big submodule but update=none
 3 files changed, 18 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 Cargo.toml
 create mode 100644 src/lib.rs
/tmp $
```

5. *qux* depends on *bar*, notice *bar*'s submodules are fetched

```
/tmp $ cargo init qux && cd qux
     Created binary (application) package
/tmp/qux $ echo -e '[dependencies.bar]\ngit = "file:///tmp/bar"' >> Cargo.toml
/tmp/qux $ time cargo update
    Updating git repository `file:///tmp/bar`
    Updating git submodule `file:///tmp/foo`

real    0m22.182s
user    0m20.402s
sys     0m1.714s
/tmp/qux $
```

Fix it by checking if a Git repository submodule should be updated when
cargo processes dependencies.

6. With the change applied, submodules with `update=none` are skipped

```
/tmp/qux $ cargo cache -a > /dev/null
/tmp/qux $ time ~/src/cargo/target/debug/cargo update
    Updating git repository `file:///tmp/bar`
    Skipping git submodule `file:///tmp/foo`

real    0m0.029s
user    0m0.021s
sys     0m0.008s
/tmp/qux $
```

Fixes #4247.

Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>

Update manifest.md

Remove comment from example toml to prose.

Auto merge of #10713 - flip1995:rust-version-env, r=epage

Expose rust-version through env var

This adds another env var that is exposed by cargo. In Clippy we would like to use that in order to efficiently check if a rust-version is set for the current package: https://github.com/rust-lang/rust-clippy/pull/8774

Currently we either have to parse the `Cargo.toml` file ourselves or use the `cargo_metadata` crate which has a notable performance impact when running `clippy-driver` on single files.

Expose rust-version through env var

Auto merge of #10676 - djmcgill:origin/master, r=weihanglo

add validation for string "true"/"false" in lto profile

### What does this PR try to resolve?
Adds a special-cased error message for when `lto` is set to the _string_ `"true"`/`"false"` which is surprisingly (I was surprised anyway) not allowed and the error message is ambiguous. The new error message makes it clear what values are accepted.
Fixes https://github.com/rust-lang/cargo/issues/10572

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

 <!-- Demonstrate how you test this change and guide reviewers through your PR.
With a smooth review process, a pull request usually gets reviewed quicker.

If you don't know how to write and run your tests, please read the guide:
https://doc.crates.io/contrib/tests -->

Uh I've not actually tested yet that's the WIP part. But put
```
[profile.dev]
lto="false"
```
in your TOML and run `cargo build`, check that you get the new error message and that it makes sense and is helpful.

### Additional information

It's worth noting that as per https://github.com/rust-lang/rust/pull/97051 this doesn't fix the _real_ problem here IMO which is that [rust's `opt_parse_bool` cli parsing](https://github.com/rust-lang/rust/blob/491f619f564a4ff9ae4cc837e27bb919d04c31be/compiler/rustc_session/src/options.rs#L456) doesn't accept true/false which certainly seems an ad-hoc historical choice to me on first glance but also it's a much bigger change to change those semantics than this error message.

Special case the string true/false error message for LTO profile arg

Auto merge of #10726 - weihanglo:test-doc-enhance, r=epage

Enhance documentation of testing

Small wording tweak.

doc: don't mention `#[test]` in cargo-bench doc

This is too details and not for averaged users.

doc: add `**Note**:` to make quote block like a note

Rephrase wordings in testing docs

- Rephrase doctest exec model as "not guranteed and may change" instead
- Mention `#[bench]` in what cargo-bench automatically runs
- Make it clear for build/rustc when mentioning bin targets auto-built

Update manifest.md

clearer example

doc: execution model of doctest

NOTE: This is an undocumented implementation details.

doc: mention `cargo test` runs test targets serially

doc: add more link references for tests guide

- Mention that in `src/` Cargo also collect doc tests.
- Remove outdated statement: Cargo no longer tests examples by default.
- Add a link to "Cargo Targets: Tests" to help people learn about it.

doc: mention binary auto-built for build,bench,test,rustc

doc: highlight `--doc` only applied on lib target

Auto merge of #10724 - ehuss:ci-disk-space, r=Eh2406

Clear disk space on CI.

Cargo's testsuite uses a considerable amount of disk space. On windows-gnu, the target directory can get over 12GB, and there is only 13GB free.  We're starting to run out of disk space, so this is a stop-gap that clears out the test data before running the smoke test which uses a fair bit of space itself.

We will probably need to think about addressing #9701 somehow, otherwise we will start running out of space as we add more tests. See the linked issues in https://github.com/rust-lang/cargo/pull/9701#issuecomment-881765517 for additional context.

Clear disk space on CI.

Auto merge of #10720 - JohnTitor:use-latest-tar, r=ehuss

Enforce to use tar v0.4.38

The latest version of `tar` crate includes https://github.com/alexcrichton/tar-rs/pull/262, which uses a bit recent timestamp when archiving.
However, [it seems rust-lang/rust uses v0.4.37](https://github.com/rust-lang/rust/blob/e0944922007e1bb4fe59809293acf4364410cccc/Cargo.lock#L5124-L5132). This PR enforces to use v0.4.38 and it would _fix_ https://github.com/rust-lang/crates.io/issues/3859 eventually.

Enforce to use tar v0.4.38

Auto merge of #10701 - danilhendrasr:master, r=weihanglo

Emit warning upon encountering multiple packages with the same name

Fixes: #10669

Auto merge of #10706 - merelymyself:master, r=epage

Guide new users to add use `super::*;` to `mod test`

### What does this PR try to resolve?

Currently, `cargo init --lib` produces examples for unit tests. However, new users will find that they are unable to use functions they defined above. This should resolve the confusion.

Fixes #10559

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

This PR does not create new features. Test this PR using the already-existing tests.

### Additional information

I didn't think this was a major change, so I did not open a RFC for it. Please let me know if I should have!

Emit warning upon encountering ambiguous deps

whitespace 2

whitespace