Support inheriting jobserver fd for external subcommands

If cargo detects the existence of a jobserver, cargo should pass the
jobserver down to the external subcommand. Here are the reasons:

1. The existence of jobserver implies the user "expects" the amount of
   job is under control. However, before this commit, external
   subcommands cannnot benefit from the global view of the jobserver.
2. `cargo-clippy` as an external subcommand migth also love to respect
   the jobserver protocol.
3. There are several well-known external subcommands calling "cargo"
   interally (cargo-fuzz, cargo-tarpaulin, etc.)

Caveats:

Job without special prefix `+` might still be considered as a sub-make
and would inherit the jobserver, though I don't see it as an issue.

According to GNU Make Manual "13.1.1 POSIX Jobserver Interaction" [^1],
if `--jobserver-auth` option is available in `MAKEFLAGS` but the file
descriptors are closed, it means that the calling `make` didn't consider
our tool awas a recursive `make` invocation. I make an assumption that
if those fds are still open, we are happy to use those jobserver tokens.

[^1]: https://www.gnu.org/software/make/manual/make.html#POSIX-Jobserver

test: external subcommand inherits jobserver

Auto merge of #10497 - Muscraft:rfc2906-part1, r=epage

Part 1 of RFC2906 - Packages can inherit fields from their root workspace

Tracking issue: #8415
RFC: rust-lang/rfcs#2906

All changes were heavily inspired by #8664 and #9684

A big thanks to both `@yaymukund` and `@ParkMyCar.` I pulled a lot of inspiration from their branches.

I would also like to thank `@alexcrichton` for all the feedback on the first attempt. It has brought this into a much better state.

All changes have been made according to the RFC as well as `@alexcrichton's` [comment](https://github.com/rust-lang/cargo/pull/8664#issuecomment-704878103).

This is part 1 of many, as described by [this comment](https://github.com/rust-lang/cargo/pull/9684#issuecomment-943567692), [this comment](https://github.com/rust-lang/cargo/pull/9684#pullrequestreview-779070283) and redefined  [by this one](https://github.com/rust-lang/cargo/pull/10497#issuecomment-1076301312).

This PR focuses on inheriting in root package, including:
- Add `MaybeWorkspace<T>` to allow for `{ workspace = true }`
- Add a new variant to `TomlDependency` to allow inheriting dependencies from a workspace
- Add `InheritableFields` so that we have somewhere to get a value from when we `resolve` a `MaybeWorkspace<T>`
  - `license_file` and `readme` are in `InheritableFields` in this part but are not `MaybeWorkspace` for reasons [described here](https://github.com/rust-lang/cargo/pull/10497#issuecomment-1076470424)
- Add a method to `resolve` a `MaybeWorkspace<T>` into a `T` that can fail if we have nowhere to pull from or the workspace does not define that field
- Disallow inheriting from a different `Cargo.toml`
  - This means that you can only inherit from inside the same `Cargo.toml`, i.e. it has both a `[workspace]` and a `[package]`
  - Forcing this requirement allows us to test the implementations of `MaybeWorkspace<T>` and the new `TomlDependency` variant without having to add searching for a workspace root and the complexity with it

Remaining implementation work for the RFC
- Support inheriting in any workspace member
- Correctly inherit fields that are relative paths
  - Including adding support for inheriting `license_file`,  `readme`, and path-dependencies
-  Path dependencies infer version directive
- Lock workspace dependencies and warn when unused
- Optimizations, as needed
- Evaluate any new fields for being inheritable (e.g. `rust-version`)
- Evaluate making users of `{ workspace = true }` define the workspace they pull from in `[package]`

Areas of concern:
- `TomlDependency` Deserialization is a mess, and I could not figure out how to do it in a cleaner way without significant headaches. I ended up having to do the same thing as last time [which was an issue](https://github.com/rust-lang/cargo/pull/9684#discussion_r728444103).
- Resolving on a `MaybeWorkspace` feels extremely verbose currently:
  ```rust
  project.homepage.clone().map(|mw| mw.resolve(&features, "homepage", || get_ws(inheritable)?.homepage())).transpose()?,
  ```
  This way allows for lazy resolution of inheritable fields and finding a workspace (in part 2) so you do not pay a penalty for not using this feature. The other bit of good news is `&features` will go away as it is just feature checking currently.

- This feature requires some level of duplication of code as well as remaking the original `TomlManifest` which adds extra length to the changes.
- This feature also takes a linear process and makes it potentially non-linear which adds lots of complexity (which will get worse in Part 2)

Please let me know if you have any feedback or suggestions!

Auto merge of #10495 - ehuss:remove-profile-panic-inherit, r=weihanglo

Remove unused profile support for -Zpanic-abort-tests

This removes the vestigial `PanicSetting::Inherit` setting.

This was initially introduced in #7460 which added `-Zpanic-abort-tests`. This was needed at the time because `test` and `dev` profiles were separate, but they were inter-mixed when running `cargo test`. That would cause a problem if the unwind/abort settings were mixed.  However, with named profiles, `test` now inherits from `dev`, so this is no longer necessary. Now that named profiles are stable, support for the old form is no longer necessary.

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

HTTP registry implementation

Implement HTTP registry support described in [RFC 2789](https://github.com/rust-lang/rfcs/pull/2789).

Adds a new unstable flag `-Z http-registry` which allows cargo to interact with remote registries served over http rather than git. These registries can be identified by urls starting with `sparse+http://` or `sparse+https://`.

When fetching index metadata over http, cargo only downloads the metadata for needed crates, which can save significant time and bandwidth over git.

The format of the http index is identical to a checkout of a git-based index.

This change is based on `@jonhoo's` PR #8890.

cc `@Eh2406`

Remaining items:
- [x] Performance measurements
- [x] Make unstable only
- [x] Investigate unification of download system. Probably best done in separate change.
- [x] Unify registry tests (code duplication in `http_registry.rs`)
- [x] Use existing on-disk cache, rather than adding a new one.

Auto merge of #10501 - ehuss:capacity-notice2, r=weihanglo

Add a notice about review capacity.

This adds a notice to let people know about the limited review capacity on the team.

Add a notice about review capacity.

-- renamed deduplicate_workspace to inheritable_workspace_fields
-- removed `[]` from error messages in favor of back-ticks

Auto merge of #10047 - jonhoo:ignore-symlink-dir, r=ehuss

Add tests for ignoring symlinks

This adds tests for the expected behavior in https://github.com/rust-lang/cargo/issues/10032. Interestingly, these tests pass (🎉). Will update that issue with more details shortly, but figured these tests were worthwhile to add to the testsuite anyway now that I've written them.

-- updated both `resolve` to only take a get_ws
-- `resolve` not takes `get_ws: impl FnOnce() -> CargoResult<T>`
-- removed `MaybeWorkspace` from `readme` and `license-file`
-- changed error messages and test names

Add tests for ignoring symlinks

-- Part 1 of RFC2906

Remove unused profile support for -Zpanic-abort-tests

Auto merge of #10494 - ehuss:deps-of-doc, r=Eh2406

Update doc string for deps_of/compute_deps.

I noticed the `compute_deps` doc string was outdated due to some recent refactorings.  This updates the doc comments to try to clarify them and make them more accurate.

Update doc string for deps_of/compute_deps.

Auto merge of #10394 - dtolnay-contrib:displayerror, r=ehuss

Consistently use crate::display_error on errors during drain

As suggested in https://github.com/rust-lang/cargo/pull/10383#discussion_r808178038 and https://github.com/rust-lang/cargo/pull/10383#discussion_r808182199.

HTTP registry implementation

Auto merge of #10482 - arlosi:refactor_load, r=Eh2406

Refactor RegistryData::load to handle management of the index cache

Enables registry implementations to signal if the cache is valid on a per-request basis.

Fixes a bug introduced by #10064 that caused Cargo not to update for several cases in a release build because it believed the index cache to be valid when it was not. The issue only occurred in release builds because debug builds verify that the cache contents is correct (by refreshing it).

Previously `current_version` was called by the index to determine whether the cache was valid. In the new model, `RegistryData::load` is passed the current version of the cache and returns an enum to indicate the status of the cached data.

r? `@eh2406`
cc `@ehuss`

Refactor RegistryData::load to handle management of the index cache itself.

This enables registry implementations to signal if the cache is valid
on a per-request basis.

Fixes a bug introduced by #10064 that caused Cargo not to update for
several cases in a release build because it believed the index cache to
be valid when it was not.

Auto merge of #10483 - cuviper:vcs--, r=Eh2406

Separate VCS command paths with "--"

When building a VCS command, there may be ambiguity if a relative path
looks like an option, like "-path" or "--path". All of the VCS commands
that we use support a bare "--" separator for non-option arguments,
which is good practice to apply here.

This does not affect the cargo CLI, as it already makes sure to use
absolute paths for these calls via `value_of_path()`.

Separate VCS command paths with "--"

When building a VCS command, there may be ambiguity if a relative path
looks like an option, like "-path" or "--path". All of the VCS commands
that we use support a bare "--" separator for non-option arguments,
which is good practice to apply here.

This does not affect the cargo CLI, as it already makes sure to use
absolute paths for these calls via `value_of_path()`.

Print only Message::Finish errors all the time

Auto merge of #10433 - Byron:fix-#10431, r=ehuss

Fix panic when artifact target is used for `[target.'cfg(<target>)'.dependencies`

With an artifact dependency like this in package `a`…

```toml
[dependencies.a]
path = "b"
artifact = "bin"
target = "$TARGET"
```

…and when using `$TARGET` like this in another package `b`…

```toml
[target.'cfg(target_arch = "$ARCHOF_$TARGET")'.dependencies]
c = { path = "../c" }
```

…it panics with `thread 'main' panicked at 'activated_features for invalid package: features did not find PackageId <dbg-info>`, but we would expect this to work normally.

### Tasks

- [x] reproduce issue in new test
   - [x] figure out why the test is fixed but the real-world example isn't
- [x] find a fix

Fixes #10431 and  #10452.

Auto merge of #10479 - weihanglo:bump-git2, r=ehuss

Bump git2@0.14.2 and libgit2-sys@0.13.2

Bump git2@0.14.2 and libgit2-sys@0.13.2

The previous libgit2-sys release forgot to include the fix of libgit2 1.4.2.
https://github.com/rust-lang/git2-rs/pull/820#issuecomment-1064284814
That might cause problems when people don't have "Git for Windows"
installed on their machines.

Undo a prior change to fix #10452

reproduce: wrong features in a build script for a shared dependency (#10452)

Remove prior hack and replace it with a proper solution

This is the diff from
https://github.com/rust-lang/cargo/pull/10433#issuecomment-1064577586
applied to the codebase with the previous hack removed.

Thanks a million to @ehuss who has the insight to find fixes like this.

Auto merge of #10448 - aeikum:fix_vendor_sync, r=weihanglo

vendor: Don't allow multiple values for --sync

The --sync argument to cargo vendor currently takes a list, which makes it easy for it to eat the final path argument:

````
cargo vendor --manifest-path foo/Cargo.toml -s bar/Cargo.toml ./test_vendor/
error: failed to read ./test_vendor/

Caused by:
  No such file or directory (os error 2)
````

Per discussion on #10441, this behavior is undesirable and hopefully used infrequently enough that we can change the UI for it. This patch will now only allow one value per --sync argument.

I didn't regenerate other doc files as it's not clear to me how/when that should be done.

vendor: Don't allow multiple values for --sync

Auto merge of #10471 - Eh2406:credential_process, r=weihanglo

Use types to make clere (credential process || token)

`RegistryConfig` represents what credentials we have read from disk. It was a
```
   token: Option<String>,
   credential_process: Option<(PathBuf, Vec<String>)>,
```
with runtime checks that they were not both `Some`.
This changes it to be an Enum `None|Token|Process`.
There is somewhat more code, but I think this is clearer.

This also changed some `Option<String>` arguments to `Option<&str>`.

dont need index in the type

Auto merge of #10316 - hi-rustin:rustin-patch-proc_macro, r=weihanglo

Warning on conflicting keys

Signed-off-by: hi-rustin <rustin.liu@gmail.com>
### What does this PR try to resolve?

close https://github.com/rust-lang/cargo/issues/10299 and close https://github.com/rust-lang/cargo/issues/10317

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

- Warning on conflicting proc_macro and crate_types keys.
- Warning on conflicting dev-dependencies, build-dependencies, and default-features keys.

at rest we can either have a credential process or a token

Auto merge of #10064 - arlosi:poll, r=Eh2406

Registry functions return Poll to enable parallel fetching of index data

Adds `Poll` as a return type for several registry functions to enable parallel fetching of crate metadata with a future http-based registry.

Work is scheduled by calling the `query` and related functions, then waited on with `block_until_ready`.

This PR is based on the draft PR started by eh2406 here [#8985](https://github.com/rust-lang/cargo/pull/8985).

r? `@Eh2406`
cc `@alexcrichton`
cc `@jonhoo`

cargo fmt

Auto merge of #10468 - weihanglo:contrib-doc-refine, r=ehuss

Refine the contributor guide

Use warn_on_deprecated

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

Warning on conflicting dev_dependencies keys of platform

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

Warning on conflicting build_dependencies keys of platform

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

Warning on conflicting default_features keys

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

Warning on conflicting build_dependencies keys

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

Warning on conflicting dev-dependencies keys

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

Warning on conflicting crate_types keys

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

Warning on conflicting proc_macro

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

Call out the contributor guide on the readme

Reuse "Before hacking on Cargo" to emphasize discussion before hacking

Auto merge of #10438 - rukai:deny_clippy, r=ehuss

Remove remaining 2 warn(clippy::*) instances

Add a section "Before hacking on Cargo"

The intent is redirecting contributor to know how we manage features and
bugs and hope they start some discussions first.

Remove warn(clippy::*)

Auto merge of #10427 - weihanglo:drop-num_cpus, r=joshtriplett

Use `available_parallelism` instead of `num_cpus`

Pull Request feedback

Auto merge of #10456 - hi-rustin:rustin-patch-network, r=alexcrichton

Wait up to one second while waiting for curl

### What does this PR try to resolve?

close https://github.com/rust-lang/cargo/issues/8516

Wait up to one second while waiting for curl.

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

1. Build cargo
2. Start a network transfer (cargo fetch).
3. Pull the network cord.
4. Wait.

Auto merge of #10460 - Eh2406:coverage, r=alexcrichton

Improve code coverage

Remove some unused and private methods, and add a test.

cc:
- https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/test.20coverage
- https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/If.20RFC.203231.20Private.20tokens.20on.20the.20command.20line

add a test for login on stdin

Remove some dead code in SourceMap

Auto merge of #10458 - Eh2406:console-history, r=ehuss

Don't recommend leaking tokens into the console history

Passing a secret on the command line leeks it into the history witch is available to other applications on the same system.

Removing the functionality is a braking change, a big ask. But it is not hard to change the docs to not recommend using `cargo login` that way.

cc:
- https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/If.20RFC.203231.20Private.20tokens.20on.20the.20command.20line
- https://github.com/rust-lang/rfcs/pull/3231#discussion_r812435273

prompt not propt

Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>

Auto merge of #10454 - cuishuang:master, r=ehuss

fix some typos

Don't recommend leaking tokens into the console history

Wait up to one second while waiting for curl

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

fix some typos

Signed-off-by: cuishuang <imcusg@gmail.com>

Auto merge of #10453 - notriddle:notriddle/vec-extend, r=weihanglo

Use `extend` instead of `push`ing in a loop

Use `extend` instead of `push`ing in a loop

Auto merge of #10449 - Eh2406:locked_version, r=alexcrichton

Use locked_version more

In #9847 we added better tracking for when a requirement came from a lockfile. This uses that tracking in a few more error messages.

Closes #10391

add a test

Use locked_version more

Wrap an error context for determining the amount of parallelism

Auto merge of #10443 - alexcrichton:disable-dependabot, r=ehuss

Disable dependabot

I don't think this has ever actually sent a meaningful version bump PR
we weren't already aware of, so unless someone else wants to be in
charge of these I'm going to go ahead and disable dependabot.

Auto merge of #10442 - Urgau:git2-update, r=alexcrichton

Update git2 dependencies

This pull-request update git2 to 0.14.1 and git2-curl to 0.15.0 and libgit2-sys to 0.13.1.

This fix a memory corruption that I have locally when running the testsuite:
```
==2338650==  Uninitialised value was created by a stack allocation
==2338650==    at 0x11FE3A0: git2::remote::Remote::fetch (remote.rs:276)
```

Disable dependabot

I don't think this has ever actually sent a meaningful version bump PR
we weren't already aware of, so unless someone else wants to be in
charge of these I'm going to go ahead and disable dependabot.

Update git2 to 0.14.1 and git2-curl to 0.15.0 and libgit2-sys to 0.13.1

A cry for help with a fix for the issue that looks like a hack.

In order not to give up and create a basis for discussion while ending
my 3h oddisey on finding a fix for today, I present something that
seems to work even though I hope there are better ways to solve this.

minor improvement to how artifact targets are handled in platform descriptions

trigger another failure by using [target.'cfg(…)'.dependencies] syntax

A fix for the previous simplified reproduction

further simplify the reproduction code

This is a hacky way of making changes while leaving everything else,
despite it being deactivated for now, in the hopes to not forget
to put additional difficulties back in once this particular issue
is fixed.

reproduce issue; this time with build dependencies

They differ as these will be built for the host, so
`FeaturesFor` will not set a target specifically.

Remove the update method on registry functions. Instead of explicitly
updating, registries now update as needed. To force a registry to
ensure the latest copy of crate metadata is available, a new method
called `invalidate_cache` is added. This method will cause the registry
to update the next time `block_until_ready` is called.

Registry functions return task::Poll to enable parallel fetching of index data.

Auto merge of #10434 - weihanglo:stop-gating-stable-features, r=alexcrichton

Stop gating stable features

Auto merge of #10395 - jonhoo:fix-10206, r=alexcrichton

Enable propagating host rustflags to build scripts

### What does this PR try to resolve?

This PR primarily fixes #10206, but in doing so it also slightly modifies the interface for the unstable `target-applies-to-host` feature (#9453), and adds the unstable `target-applies-to-host-kind` flag to mirror `target-applies-to-host` for build scripts and other host artifacts.

The commit messages have more in-depth discussion.

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

The test case from #10206 now works rather than producing an error. It has also been added a regression test case. A few additional test cases have also been added to handle the expected behavior around rustflags for build scripts with and without `target-applies-to-host-kind` enabled.

### Additional information

1. This changes the interface for `target-applies-to-host` so that it does not need to be specified twice to be used. And it can still be set through configuration files using the `[unstable]` table. However, we may(?) want to pick a stable format for in-file configuration of this setting unless we intend for it to only ever be a command-line flag.
2. It may be that `target-applies-to-host-kind` is never behavior we want users to turn on, and that it should therefore simply be removed and hard-coded as being `false`.
3. It's not entirely clear how `target-applies-to-host-kind` should interact with `-Zmultitarget`. If, for example, `requested_kinds = [HostTarget, SomeOtherTarget]` and `kind.is_host()`, should `RUSTFLAGS` take effect or not? For the time being I've just hard-coded the behavior for single targets, and the answer would be "no".

Auto merge of #10425 - epage:search, r=alexcrichton

feat(search): Highlight search term

This supersedes #10116.  For the requested colored-output tests, this followed the pattern of the `fix` tests which just detects whether colored output is used or not.  The `cache_messages` actually verify the output is colored but that is because it can just compare to a rustc call's output.  Getting the colored output correct by hand in a test (with all of the resets) is a bit messy and would be brittle.

This was done in an exercise in exploring ways to generalize colored output support in preparation for `cargo-add` doing some colored output as well.

I converted all output calls to use this approach, even if coloring wasn't used, for consistency.  I considered coloring the overflow message but decided to hold off on that for now (either a warning-yellow or a hint-gray).

Fixes #9918

Stop gating feature "edition2021"

Stop gating feature "resolver"

Stop gating feature "named-profiles"

Stop gating feature "profile-overrides"

Stop gating feature "rename-dependency"

Stop gating feature "edition"

Look at FeaturesFor:: to decide if a dependency participates in feature resolution

Fixes #10431.

reproduce #10431

Auto merge of #10428 - Urgau:check-cfg-features-rustdoc, r=ehuss

Add -Z check-cfg-features support for rustdoc

This PR is a follow to https://github.com/rust-lang/cargo/pull/10408 where support for compile-time checking of features was implemented for `rustc`.

At the time `rustdoc` support wasn't yet merged, but now that it has been [merged](https://github.com/rust-lang/rust/pull/94154), this pull-request add support for it in the `doc` and `test --doc` (doctest) mode.

r? `@alexcrichton`

Auto merge of #10388 - weihanglo:issue-10356, r=ehuss

Override target crate-type for `cargo rustc --crate-type`

Auto merge of #10167 - hi-rustin:rustin-patch-test, r=ehuss

Use 1.51.0 in old cargos test

Remove TODO.
If the default toolchain is the same as "stable", just skip the `avoids_split_debuginfo_collision` test.

Auto merge of #10429 - cuviper:config-verbosity, r=ehuss

Fix term.verbose without quiet, and vice versa

The match pattern only looked for `Some(false)`, missing `None`.

Fix term.verbose without quiet, and vice versa

The match pattern only looked for `Some(false)`, missing `None`.

Add -Z check-cfg-features support for rustdoc

Check 1.60 behavior

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

Use `available_parallelism` instead of num_cpus

`std::thread::available_parallelism` has been stabilized since 1.59.0.

Also, we don't want to block timing data output, so if parallelism
data is not available the table will display `ncpu=n/a` instead.

Skip avoids_split_debuginfo_collision on stable

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

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