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.
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>`.
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.
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`
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.
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
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 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)
```
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.
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.
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".
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
