Port cargo to clap3
### What does this PR try to resolve?
This moves cargo to the latest major version of clap.
This supersedes #10259 and #10262
### How should we test and review this PR?
For testing, I mostly relied on existing tests. I did manually validate that `cargo run <non-escaped command args>` behaved the same between both
```console
$ cargo run release --help
Finished dev [unoptimized + debuginfo] target(s) in 0.22s
Running `target/debug/cargo-release release --help`
cargo-release 0.18.8
...
$ cargo run --manifest-path ../cargo/Cargo.toml -- run release --help
Finished dev [unoptimized + debuginfo] target(s) in 0.05s
Running `/home/epage/src/personal/cargo/target/debug/cargo run release --help`
Finished dev [unoptimized + debuginfo] target(s) in 1.31s
Running `target/debug/cargo-release release --help`
cargo-release 0.18.8
...
```
For reviewing, I split out each deprecation resolution into a separate commit so its easy to focus on more mechanical changes (most of the deprecation fixes) from interesting ones (the port, the `Arg::multiple` deprecation)
### Additional information
- One parser change found by `cargo_config::includes` is that clap 2
would ignore any values after a `=` for flags.
`cargo config --show-origin` is a flag but the test passed `--show-origin=yes` which
happens to give the desired result for that test but is the same as
`--show-origin=no` or `--show-origin=alien-invasion`.
- `ArgMatches` now panics when accessing an undefined argument but clap
takes advantage of that for sharing code across commands that have
different subsets of arguments defined. I've extended clap so we can
"look before you leap" and put the checks at the argument calls to
start off with so its very clear what is tenuously shared. This
allows us to go in either direction in the future, either addressing
how we are sharing between commands or by moving this down into the
extension methods and pretending this clap feature doesn't exist
- On that topic, a test found clap-rs/clap#3263. For now, there is a
hack in clap. Depending on how we fix that in clap for clap 4.0, we
might need to re-address things in cargo.
- `value_of_os` now requires setting `allow_invalid_utf8`, otherwise it
asserts. To help catch this, I updated the argument definitions
associated with lookups reported by:
- `rg 'values?_os' src/`
- `rg 'values?_of_os' src/`
- clap now reports `2` for usage errors, so we had to bypass clap's
`exit` call to keep the same exit code.
- `cargo vendor --sync` did not use `multi_opt` and so it has both
multiple occurrences **and** multiple values. If we want to deprecate
this, we'll need `unstable-grouped` to be stablized (or pin our clap
version) and ensure each group has only 1 value.
- One parser change found by `cargo_config::includes` is that clap 2
would ignore any values after a `=` for flags.
`cargo config --show-origin` is a flag but the test passed `--show-origin=yes` which
happens to give the desired result for that test but is the same as
`--show-origin=no` or `--show-origin=alien-invasion`.
- The parser now panics when accessing an undefined attribute but clap
takes advantage of that for sharing code across commands that have
different subsets of arguments defined. I've extended clap so we can
"look before you leap" and put the checks at the argument calls to
start off with so its very clear what is tenuously shared. This
allows us to go in either direction in the future, either addressing
how we are sharing between commands or by moving this down into the
extension methods and pretending this clap feature doesn't exist
- On that topic, a test found clap-rs/clap#3263. For now, there is a
hack in clap. Depending on how we fix that in clap for clap 4.0, we
might need to re-address things in cargo.
- `value_of_os` now requires setting `allow_invalid_utf8`, otherwise it
asserts. To help catch this, I updated the argument definitions
associated with lookups reported by:
- `rg 'values?_os' src/`
- `rg 'values?_of_os' src/`
- clap now reports `2` for usage errors, so we had to bypass clap's
`exit` call to keep the same exit code.
BREAKING CHANGE: API now uses clap3
Be resilient to most IO error and filesystem loop while walking dirs
Let `PathSource::walk` be resilient to most IO errors and filesystem loop.
This PR also
- Add a test validating the resilience against filesystem loop to prevent regression.
- Emit warning when filesystem loop found while walking the filesystem. This is the only way I can think of now to solve #9528Fixes#10213.
Cargo has had pipelining enabled by default for a long time, without
issue. Remove support for `build.pipelining = false`. (Continue parsing
the option from the config file, but ignore it.)
Remove `build_script::build_script_scan_eacces` test case because cargo
ignores it and returns its path during a `cargo build`. The caller still
has a chance to hit the IO error if they does access it.
Stabilize the `strip` profile option, now that rustc has stable `-C strip`
https://github.com/rust-lang/rust/pull/90058/ stabilized `-Z strip` as `-C strip`. Stabilize the corresponding Cargo option.
Update the documentation to move it from the unstable reference to the profiles documentation.
Update the tests to account for stabilization.
https://github.com/rust-lang/rust/pull/90058/ stabilized `-Z strip` as
`-C strip`. Stabilize the corresponding Cargo option.
Update the documentation to move it from the unstable reference to the
profiles documentation.
Update the tests to account for stabilization, but make them no-ops on
stable/beta for now until rustc 1.58 releases.
When typing in a single character shortcut as a capital, it always
returns `b` as the suggestion as every one-letter abbreviation
is a lev distance 1 away from the capitalized one.
By making the levenshtein distance case insensitive, the case-mismatched
one-letter abbriviation (e.g. `C` to `c`) will be suggested, rather
than `b`
Detect filesystem loop during walking the projects
Resolves#9528
~~This PR also adds a new dependency `same-file` but since it's already a
dependency of `cargo-util`, so nothing added actually.~~
Use `walkdir` to detect filesystem loop and gain performance boost!
Support `term.quiet` configuration
Fixes#10128
This follows the existing support for `--verbose` and `term.verbose`.
I've renamed the related tests to be a bit clearer now there are more cases, and the existing quiet tests now prove that they hide the cargo log.
I'm unsure whether I'm supposed to regenerate the documentation as part of this?
Display alias target on 'cargo help <alias>`
```
Previously, `cargo help <alias>` resolved the alias and displayed the
help for the targeted subcommand. For example, if `br` were aliased to
`build --release`, `cargo help br` would display the manpage for
cargo-build.
With this patch, it will print "'br' is aliased to 'build --release'".
```
Addresses issue #10138.
This is my first patch to Cargo. I attempted to follow the style of the surrounding code. Please let me know if any changes are required: happy to make them. In particular, I wasn't sure if any tests exist for this path.
delete --host command and message
close https://github.com/rust-lang/cargo/issues/10121
The warning for this command has been around for a long time, and it seems safe to delete it now.
According to Alex's words in the issue, I think he supports deletion. I'm sorry if I misunderstood it and feel free to close it.
Improve I/O error message for fingerprint of build script
It is a bit rough but I don't think there is a network I/O error
in `pkg_fingerprint`. Checking only `io::Error` type should be fine.
Resolves#9881
Explicitly mark aliases in `cargo list`.
This I think makes it a little clearer that these are aliases, and matches the form used for built-in aliases.
Don't emit "executable" JSON field for non-executables.
The "executable" field of JSON artifact messages was accidentally filled (with the path to `index.html`) when documenting a binary target. This fixes it so that it is null.
Closes#10149
Document lib before bin.
This changes it so that documenting a library is required to finish before documenting a binary. The issue is that the binary may have intra-doc links to the library. If they are documented concurrently, then the links will sometimes fail (since it is a race). Or, if doing `cargo doc --bins`, then the library docs wouldn't exist at all.
Note that in the tests this introduces some more name collisions if you just run `cargo doc --bins` and there is a colliding library/binary name. There is some risk that someone might be trying to run the commands separately to get around the collision error, but I think it is unlikely.
This changes the behavior so that simple aliases that directly alias a
subcommand (with no arguments) pass-through to that subcommand, while
complex aliases (with arguments) show the alias.
So for example, `cargo help b` will show the manpage for `cargo-build`,
while `cargo help my-alias`, aliased to `build --release`, will show
"`my-alias` is aliased to `build --release`".
Support abbreviating `--release` as `-r`
Of the options people regularly pass to cargo, `--release` seems by far
the most common. Yet even on the command line, we expect people to type
out `--release`.
Add a short version `-r`, and add some tests in the testsuite that
confirm it works.
Fix some tests with output collisions.
This fixes some tests which run afoul of creating colliding outputs (tracked in #6313). In particular, these tests are creating duplicate pdb files on Windows because they have a binary and a library (dylib) with the same name. This is causing significant issues on rust-lang's CI (https://github.com/rust-lang/rust/issues/81890) where the MSVC linker is failing with a mysterious LNK1201 error. Presumably two LINK.exe processes are trying to write to the same PDB file at the same time, which causes it to fail.
Ideally this shouldn't happen, but I don't really have any ideas on how to resolve it, as the name of the PDB has some importance.
I have not been able to reproduce the LNK1201 error. My hope is that this change will help alleviate the issue, though.
I updated the `doc_all_member_dependency_same_name` test to illustrate that it is hitting a collision, which is a fundamental part of that test (and something we should probably figure out how to resolve in the future).
Improve unused patch message when source URLs mismatched
Resolves#8690
`Resolve.unused_patches` does not contains info about which source
URLs they are going to patch. As a result, we cannot provide a precise
message but only list all possible URLs of the packages with the same
name in the resolved graph.
There is a little flaw that if multiple patches are patching the same
package, the source URL of the used one would be shown as a possible
URL in the warning.
Of the options people regularly pass to cargo, `--release` seems by far
the most common. Yet even on the command line, we expect people to type
out `--release`.
Add a short version `-r`, and add some tests in the testsuite that
confirm it works.
`Resolve.unused_patches` does not contains info about which source
URLs they are going to patch. As a result, we cannot provide a precise
message but only list all possible URLs of the packages with the same
name in the resolved graph.
There is a little flaw that if multiple patches are patching the same
package, the source URL of the used one would be shown as a possible
URL in the warning.
Fix a couple issues with cyclic features and dev-dependencies
This fixes two issues with cyclic features and dev-dependencies:
* `cargo tree` would enter an infinite loop for cyclic features.
* The resolver would return a confusing error if a cyclic dev-dependency attempted to enable a feature on its parent that resulted in a cycle. This fixes it to resolve correctly.
Fixes#10101
