Fix git2 safe-directory disable
The call to `set_verify_owner_validation` was not getting called unless a network configuration was found. This means in the common case that `cargo new` will fail when there is a safe-directory error. This fixes the issue by making sure that `set_verify_owner_validation` is called before the early-exits in `init_git_transports`.
Fixes#11365
fix: return non UTF-8 error message
Fixes https://github.com/rust-lang/cargo/issues/11311
### Test Steps
1. Create a new empty Git repository
2. Create a `.gitignore` that is not valid UTF-8, for instance `printf '\xFF\xFE' > .gitignore`
3. `cargo init`
Extract `two_kinds_of_msg_format_err` message to de-duplicate it
### What does this PR try to resolve?
Extract `two_kinds_of_msg_format_err` message to de-duplicate it.
I guess this would be helpful for changing this message.
### Additional information
Just found it when I read the code. So if you prefer the former code style, please feel free to close my PR.
Fix wait-for-publish with sparse registry
The `wait-for-publish` feature doesn't work when publishing a new version of an existing crate on a sparse registry.
The `invalidate_cache` method doesn't clear the `fresh` list, so repeated requests just use the in-memory data if it's available. This didn't show up in the tests, because the test only simulated the `not found` to `crate available` transition, rather than the `old file` to `crate available` transition.
This change modifies the test by capturing the publish request, then deferring it until after later request for the index file.
r? `@epage`
Fixes#11314
Add `registries.crates-io.protocol` docs
### What does this PR try to resolve?
close https://github.com/rust-lang/cargo/issues/11343.
Add `registries.crates-io.protocol` docs to explain this unstable option.
chore: Upgrade dependencies
This upgrades several dependencies to the latest "major" release. The original intent was just to get onto the latest snapbox but I noticed several others that could be updated and thought "why not".
- `snapbox` broke compatibility on less used APIs
- Its unclear from the docs if `miow` or `remove_dir_all` even broke compatibility
I did not touch `mdman` as that has several large, stale deps
Clean more aggressively in CI
The Windows x86_64 gnu CI job is running dangerously low on disk space. This PR adds another step to delete test output more aggressively. The test output with x86_64-pc-windows-gnu is nearly 9.5GB. The benchmark step is adding about 1GB of space (unfortunately it is rebuilding cargo, which may be hard to avoid without a workspace).
Eventually we should probably look at figuring out how to reduce the amount of disk space used by the testsuite. Perhaps something like #9701 (see comments there). Or, making aggressive changes to the tests themselves. Many tests can probably be changed to use `cargo check` instead of `cargo build` (or maybe even `cargo tree`). We can default to not generating debuginfo. Or perhaps there are other changes to put the tests on a diet.
Remove remove_dir_all
This removes the `remove_dir_all` dependency. It is no longer needed, as there has been significant improvements to std's implementation over the years (particularly recently). This improves the performance of running cargo's testsuite on my machine from 8m to 2m 30s (!!).
This was added in #7137 to deal with some issues with symbolic links. I believe those seem to be resolved now.
Note that std's implementation is still not bullet proof. In particular, I think there are still some cases where a file can be locked by another process which prevents it from being removed. There are some more notes about this at https://github.com/rust-lang/cargo/pull/7042#issuecomment-504081900 (and various other places linked there).
Closes#9585
test(publish): Cover more wait-for-publish cases
These came from trying to guess what cases are causing problems in #11314. Unfortunately, can't reproduce it so far but figured it'd be good to keep these around.
Revert #11183
This reverts commit d4c38af1202c8b24fce6b2ad170c520017e059b9, reversing changes made to 92d8826ed4b7dfd5dd60c75bcc86da4032b00899.
Fixes#11330
---
The root cause is that [`map_to_features_for`] takes care of `unit_for.host_features` from parent unit, but [here] we only want to know whether the dependency is for host or not.
We could have an ad-hoc `FeaturesFor` construction there, but I'd rather revert it at this moment. The interaction between `UnitFor` and `FeaturesFor` bites me every time 😭.
After this revert, if we want to resolve#10526 again. The fastest way is doing the following:
```diff
diff --git a/src/cargo/core/compiler/unit_dependencies.rs b/src/cargo/core/compiler/unit_dependencies.rs
index 9319a19e0..14cc84941 100644
--- a/src/cargo/core/compiler/unit_dependencies.rs
+++ b/src/cargo/core/compiler/unit_dependencies.rs
`@@` -1103,7 +1103,7 `@@` impl<'a, 'cfg> State<'a, 'cfg> {
// If this is an optional dependency, and the new feature resolver
// did not enable it, don't include it.
if dep.is_optional() {
- let features_for = unit_for.map_to_features_for(dep.artifact());
+ let features_for = FeaturesFor::from_for_host(unit_for.is_for_host());
if !self.is_dep_activated(pkg_id, features_for, dep.name_in_toml()) {
return false;
}
```
[`map_to_features_for`]: 810cbad9a1/src/cargo/core/profiles.rs (L1043)
[here]: 810cbad9a1/src/cargo/core/compiler/unit_dependencies.rs (L1102)
