Clippy
### What does this PR try to resolve?
A few more small anti-patterns from our code base. Each in their own commit, found by turning on a clippy warning and manually reviewing the changes. Most of the changes are from switching to `let-else`.
### How should we test and review this PR?
Internal refactoring and tests still pass.
### Additional information
I know we don't like "fix clippy" PR's. Sorry.
On the other hand having reviewed for these lints, I wouldn't mind turning them to warn. 🤷
Prerelease candidates error message
### What does this PR try to resolve?
Error messages reporting on versions that do not match the request incorrectly ignore pre-release versions. This is because the version requirement `"*"` cannot match prerelease versions. #12315
### How should we test and review this PR?
Sorry for the large amount of white space changes, fmt got to fmt. 🤷♂️
The process was:
- Revise commit from #12316 (thanks to `@loloicci)` that change the requirement from `"*"` to `Any`
- Move the handling of our special "did you mean to specify a pre-release" code and update tests
- some small re-factoring
### Additional information
The old "did you mean to specify a pre-release" #7191 check only occurred when version requirement does not match any versions and you depended on a package that did not have any non-prerelease versions. Making it rarely useful.
The new one will appear any time your version requirement does not match any versions and the package does have pre-release versions. Which may be too common.
I'm open to suggestions for better heuristic.
It's also not clear that the new message make sense in the case of patched versions.
refactor: Consolidate clap/shell styles
### What does this PR try to resolve?
This is a follow up to #12578 to reduce duplication of terminal styling.
This still leaves styling in `color_print::cstr!`.
This is also prep for copy/pasting into `clap-cargo` for others to use. Another step might be to extract `cargo::util::style` into its own crate.
### How should we test and review this PR?
We have no styling tests so this can only be verified by inspection or running the commands
### Additional information
I chose `anstyle` for expressing these as its an API designed specifically for stable style definitions to put in public APIs.
libgit2 fixed upstream
### What does this PR try to resolve?
This "FIXME" points to https://github.com/libgit2/libgit2/issues/2514 witch has bean fixed for... 8 years. So maybe it is no longer needed.
### How should we test and review this PR?
By adding panic messages I was able to demonstrate that there were tests hitting this code path. Then I removed the "FIXME" and had the test still pass.
Index summary enum
### What does this PR try to resolve?
This is a tiny incremental part of allowing registries to return richer information about summaries that are not available for resolution. Eventually this should lead to better error messages, but for now it's just an internal re-factor. Discussion of the overall approach is at https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/better.20error.20messages.20for.20filtered.20versions.2E
### How should we test and review this PR?
Internal re-factor and tests still pass.
feat(help): Add styling to help output
### What does this PR try to resolve?
Try to make `--help` output easier to parse by using terminal styling
Screenshots:
*(`nargo` is my shell script wrapping `cargo run --manifest-path cargo/Cargo.toml`)*
### How should we test and review this PR?
At this time, the only styling snapshotting library I know of is a pain to use, so testing this requires manually running the commands which I did. Screenshots are included for easier evaluation of the general idea.
Snapshotting of the plain text output ensures we don't have accidental formatting regressions from this change since the formatting isn't as obvious from looking at the code.
### Additional information
Traditionally, cargo has disabled clap's styled output. My assumed
reason is that cargo mixes custom help output with auto-generated and
you couldn't previously make it all styled.
Clap 4.2 allowed users to pass in strings styled using ANSI escape
codes, allowing us to pass in styled text that matches clap, unblocking this. In clap
4.4.1, clap gained the ability for the user to override the style.
In this PR, I decided to use the new 4.4.1 feature to style clap's
output to match the rest of cargo's output. Alternatively, we could use
a more subdue style that clap uses by default.
I used the `color-print` crate to allow something almost html-like for styling `&static str`. Alternatively, we could directly embed the ANSI escape codes harder to get write, harder to inspect), or we could do the styling at runtime and enable the `string` feature in clap.
I decided to *not* style `Arg::help` messages because
- It might be distracting to have the descriptions lit up like a
christmas tree
- It is a lot more work
The one exception I made was for `--list` since it is for a
psuedo-command (`...`) and I wanted to intentionally draw attention to
it.
#12593 made styling of `cargo -h` cleaner imo.
#12592 and #12594 were improvements I noticed while doing this.
Ues strip_prefix for cleaner code
### What does this PR try to resolve?
In https://github.com/rust-lang/cargo/pull/12629#pullrequestreview-1614154046 Ed pointed out how much cleaner the code can be using `strip_prefix`, so I found a bunch more places where we should be using it.
### How should we test and review this PR?
Internal refactor and test still pass.
fix: don't print _TOKEN suggestion when not applicable
### What does this PR try to resolve?
When a registry token cannot be found, or a token is invalid, cargo displays an error recommending either `cargo login` or the appropriate environment variable.
For example:
```
error: no token found for `alternative`, please run `cargo login --registry alternative`
or use environment variable CARGO_REGISTRIES_ALTERNATIVE_TOKEN
```
With `-Z credential-process`, if `cargo:token` is not in `registry.global-credential-providers` or `registries.<NAME>.credential-provider` the suggested environment variable will not work.
Fixes#12642 by not including the `_TOKEN` environment variable if `cargo:token` is not enabled as a credential provider.
### How should we test and review this PR?
Two tests `not_found` and `all_not_found` cover this case by having a registry-specific and global credential providers respectively that return `not-found`.
Other tests that emit this error are not affected, since they still have the `cargo:token` provider available.
Bump cargo-credential-1password to v0.4.0
`cargo-credential` updated to version `0.4.0` in #12622. This updates `cargo-credential-1password` to `0.4.0` as well so it can be published to crates.io.
Error out if `cargo clean --doc` is mixed with `-p`.
This changes `cargo clean --doc -p foo` to generate an error instead of ignoring the `-p` flag. There is still an outstanding issue https://github.com/rust-lang/cargo/issues/8790 tracking this. It *should* support `-p`, but until it is supported, I think cargo should tell you that the flag is ignored. This is also in preparation for some code changes in #12634 which needs to handle any combination of various different clean flags.
