Fewer temporary needless strings
### What does this PR try to resolve?
I noticed a few places where we were using `InternedString::to_string()` in places where we just needed a hash key or to display it. In these situations we could avoid a memory allocation by using the `InternedString` directly. I used the clippy `disallowed-methods` to look through all of the places who called `to_string` on an `InternedString`, and fixed all the places where it was a straightforward change to remove it. I don't think any of them matter in practice. But doing less work can't hurt.
### How should we test and review this PR?
This was an internal re-factor, and the tests still pass.
fix(help): Provide better commands heading for styling
In working on #12578, I felt it would be weird to style the entire statement about commands but it also felt weird to not style it. So this change explores an alternatively way of communicating the information.
This addresses the ordering issue of for one of the problems from #12599.
The intent behind the `path_pkg` check is to make sure we update
workspace members in the lockfile if their version number changed.
In this case, we don't need to recursively walk, because the change
doesn't affect dependencies. However, we also shouldn't *prevent*
recursive walks which is what we are doing today, both for packages
marked to keep and for packages that have been "poisoned". So we fix
this by moving that call after all recursive adds are complete so as to
not interfere with them.
fix(update): Clarify meaning of --aggressive as --recursive
When working on cargo-upgrade, I found the meaning of `--aggressive` confusing and named it `--recursive` there.
Renaming this in `cargo update` (with a backwards compatible alias) was referenced in #12425.
fix typo: "default branch branch" -> "default branch"
Fix a typo in the doc about git dependencies, I think the second "branch" word might not be needed.
fix: add error for unsupported credential provider version
Cargo currently ignores the version in the `CredentialHello` message, and proceeds to use version `1` regardless of what the credential provider claims it can support.
This change does the following:
* Adds a new error if Cargo doesn't support any of the supported protocol versions offered by the provider.
* Kills the credential provider subprocess if it fails. This prevents it from hanging or printing spurious errors such as "broken pipe" when it's attempting to read the next JSON message.
* Adds a new test for an unsupported credential provider protocol.
fix(help): Explain --explain
In working on #12578, I'm focusing on each help string to decide how it should be handled and I noticed this. It feels weird to explain something in terms of another command's CLI, so I took `rustc --help`s message and added `rustc` to clarify it.
Looking back, the flag was added in #2551 with the message we have today. Nothing seems to really be said about it.
In reflecting on this, I'm not 100% convinced and am open to other opinions.
fix(help): Remove redundant information from new/init
Auditing all of the `--help` in prep for #12578 and noticed that we list the VCS information twice, once on our end and once by clap.
In working on #12578, I felt it would be weird to style the entire
statement about commands but it also felt weird to not style it. So
this change explores an alternatively way of communicating the
information.
In working on #12578, I'm focusing on each help string to decide how it
should be handled and I noticed this. It feels weird to explain
something in terms of another command's CLI, so I took `rustc --help`s
message and added `rustc` to clarify it.
Looking back, the flag was added in #2551 with the message we have
today. Nothing seems to really be said about it.
In reflecting on this, I'm not 100% convinced and am open to other
opinions.
fix(lints): Fail when overriding inherited lints
### What does this PR try to resolve?
Overriding of inherited lints was reserved for the future but as pointed out in https://github.com/rust-lang/cargo/issues/12115#issuecomment-1695293006, we aren't failing on these when we should but silently ignoring the overrides.
This turns it into a hard error.
In fixing this, I had to add a `#[serde(expecting)]` attribute to maintain behavior on an error case (otherwise it would say "expecting struct WorkspaceLints"). Since this drew the error message to my attention, I also tweaked it to make it more specific.
### How should we test and review this PR?
Commits are broken down by the relevant tests and fixes to make the intended behavior changes obvious.
cargo install: suggest --git when package name is url
### What does this PR try to resolve?
Improve the error message when specifying a URL for a package name in `cargo install`.
Fixes#10485
### How should we test and review this PR?
Just cargo test and trying a common case like `cargo install https://github.com/rust-lang/cargo`
### Additional information
I found this PR after finishing this one: #10522
But it seems have a larger scope to refactor some of the related code.
Perhaps this one would be easier to merge and that one could focus on the refactor, otherwise sorry for the noise and feel free to close.
Improve logout message for asymmetric tokens
When doing `cargo logout` with an asymmetric token, it currently always succeeds with no message printed.
This changes the `cargo:paseto` provider to match the other providers and respond with `NotFound` if the user is not logged in. It also adds a message to indicate that the token was successfully removed (if it existed).
I assume the reason these aren't all individual tests is test-time but
if we divide by success/failure, I'll need to duplicate things to handle
partial versions.
Overall, I feel like this makes the tests make more sense.
When working on cargo-upgrade, I found the meaning of `--aggressive`
confusing and named it `--recursive` there.
Renaming this in `cargo update` (with a backwards compatible alias) was
referenced in #12425.
fix(update): Make `-p` more convenient by being positional
Generally, cargo avoids positional arguments. Mostly for the commands that might forward arguments to another command, like `cargo test`. It also allows some flexibility in turning flags into options.
For `cargo add` and `cargo remove`, we decided to accept positionals because the motivations didn't seem to apply as much (similar to `cargo install`).
This applies the pattern to `cargo update` as well which is in the same category of commands as `cargo add` and `cargo remove`.
As for `--help` formatting, I'm mixed on whether `[SPEC]...` should be at the top like other positionals or should be relegated to "Package selection". I went with the latter mostly to make it easier to visualize the less common choice.
Switching to a positional for `cargo update` (while keeping `-p` for backwards compatibility) was referenced in #12425.
Set tracing target for networking messages.
This changes the log messages for messages related to network traffic to use the "network" tracing target. This makes it easier to do `CARGO_LOG=network=trace CARGO_HTTP_DEBUG=true` instead of trying to figure out which modules to include (and to avoid `CARGO_LOG=trace` which can be too noisy). For example, #12290 moved the location of some log messages to a different module, which broke the documented workflow of using `CARGO_LOG=cargo::ops::registry=debug` to get networking information.
feat(resolver): **Very** preliminary MSRV resolver support
### What does this PR try to resolve?
A bare bones implementation of an MSRV resolver that is good enough for people running on nightly when they really need it but is not ready for general use.
Current limitations
- Does not honor `--ignore-version`
- Gives terrible error messages
- Nothing is done yet regarding `cargo install`
- Doesn't inform the user when choosing non-latest
These will be noted in #9930 on merge.
Implementation wise, this is yet another hack (sorry `@Eh2406).` Our expectation to get this GA is to refactor the resolver to make the cargo/resolver boundary look a little more like the cargo/pubgrub boundary so we can better control policy without any of these hacks which will also make having all of the policy we need for this easier to maintain.
This is a part of #9930
### How should we test and review this PR?
Per commit
Update git2
This is a routine update of libgit2.
Changelog: https://github.com/rust-lang/git2-rs/blob/master/CHANGELOG.md#0180---2023-08-28
There is a pretty large number of changes, but I don't think any of them are particularly of interest in terms of changes users will see. Most of the changes are opt-in and we don't opt-in to them (SHA256, Windows schannel, or shallow clone).
