upgrade gitoxide to v0.54
This reduces the binary size and fixes an exploitable bug that could allow
code execution by injection arguments into hostnames of ssh URLs.
##### Binary Sizes (Release)
* `master`: 27930520
* this branch: 27869304 - a whopping 61216B less. I assume this will get worse again once more functionality will be used in future PRs.
##### Possible Vulnerability
In versions prior to v0.54, running the following would cause the calculator app to be started on MacOS:
```
❯ gix clone 'ssh://-oProxyCommand=open$IFS-aCalculator/foo'
```
Now it prints `Error: Host name '-oProxyCommand=open-aCalculator' could be mistaken for a command-line argument`.
Given the nature of builds with `cargo` and the availability of build scripts, I think `cargo` isn't prone to this issue. However, I thought it was good to upgrade anyway.
Please note that a CVE doesn't exist yet, but I will check with Rustsec on how to proceed with this.
CC `@Shnatsel`
### Tasks
* [x] fix tests - the bug was introduced in 74ce8639e8 and it leads the local symref `refs/remotes/origin/HEAD` to point to a non-existing branch.
- This is a feature, but one with the shortcoming that it's allowed to point to a none-existing ref, and that ref is not automatically created, yet, and it's not covered by a refspec. Previously it would just let the symbolic ref point to the peeled object that is known.
Buffer console status messages.
This adds buffering to some of the console output. This can help with interleaved output, particularly with things like the log output interleaving with status messages. This fixes that interleaving by atomically writing the entire status message, which in turn, helps fix some spurious errors such as https://github.com/rust-lang/cargo/issues/12639.
I'm uncertain what the performance impact of this change might have. It might improve performance, since there should be a lot fewer syscalls, and I suspect terminals will be able to handle it more efficiently (and particularly across a network connection). However, I don't know if that will have a noticeable impact.
Only the "status" messages are buffered. Everything else is still unbuffered as before.
Fix spurious errors with networking tests.
This fixes an issue where some networking tests could behave erratically. In particular, the `registry_auth::token_not_logged` has been failing somewhat often (see https://github.com/rust-lang/cargo/issues/12639). The issue is that curl can behave inconsistently based on whether or not it immediately detects that the connection has closed or not, which is not done consistently. HTTP 1.1 defaults to `Connection: open`, so this mini HTTP server was essentially not standards compliant. `Connection: close` tells curl to expect the connection to close ([ref](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection)).
refactor(TomlManifest): fail when package_root is not a directory
### What does this PR try to resolve?
Currently, if you're trying to use `TomlManifest::to_real_manifest`, and
you pass in something incorrect as the `package_root`, such as the path
to the package's manifest, you will get a weird error that looks like
this:
```
can't find library `dummy_lib`, rename file to `src/lib.rs` or specify lib.path
```
This is not very helpful, so this change makes us check that
`package_root` is a directory, and reports an error early on if it
isn't.
`registry_key` should always be `crates-io` when `is_crates_io()` is true
This also removes the test verifying `Debug` output,
whose format doesn't need to be guaranteed.
Both `name` and `alt_registry_key` are mainly used for displaying.
We can safely merge them into one enum.
However, `alt_registry_key` is also used for telling if a SourceId is
from `[registries]` so we need to provide functions to distinguish that.
Currently, if you're trying to use `TomlManifest::to_real_manifest`, and
you pass in something incorrect as the `package_root`, such as the path
to the package's manifest, you will get a weird error that looks like
this:
```
can't find library `dummy_lib`, rename file to `src/lib.rs` or specify lib.path
```
This is not very helpful, so this change makes us check that
`package_root` is a directory, and reports an error early on if it
isn't.
chore(ci): Ignore patch version in MSRV
1. Its extra churn to be forced to update patch releases
2. #12654 adds `cargo hack` which doesn't handle MSRV patch versions well
fix: use channel-specific link for registry auth error
The current error message for attempting to use a private registry without a credential provider will be a dead link until it's stabilized in 1.74. This makes the URL dependent on the channel.
r? `@ehuss`
Add some enhancements to `cargo clean`
### What does this PR try to resolve?
This adds some enhancements to `cargo clean` that fell out as a result of some refactorings in #12634 for supporting an interface for cleaning from other places in cargo, and these were relatively easy to add and assist with testing in #12634.
The changes are:
- Introduce some refactoring to offer a cleaning interface that can be used elsewhere in cargo.
- Adds a `--dry-run` CLI option which will print what `cargo clean` will delete without deleting it. **NOTE** This PR makes the flag insta-stable. I don't figure there is too much that can be learned about it keeping it unstable, though we could change that. #12634 has this flag gated with `-Zgc`.
- Adds a summary line at the end of the `cargo clean` operation that indicates how much was deleted.
### How should we test and review this PR?
Note that this PR also includes the changes from #12635 and #12637. Those commits can be dropped if those PRs are merged.
For the most part, this involves wrapping the cleaning operations in a `CleanContext` which provides an interface for performing cleaning operations. The dry run is just a flag that is checked at the deletion points. The summary data is also collected at those same points.
The previous status line was a little awkward in the way it combined
both counts. I don't think showing the directories is particularly
interesting, so they are only displayed when no files are deleted.
This refactors some of the `cargo clean` code to wrap the "cleaning"
operation in a `CleanContext` so that the context can be passed to other
parts of cargo which can perform their own cleaning operations.
There are some minor changes in the error messages to prepare for
cleaning operations that aren't directly related to the build directory.
