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 d4c38af120, reversing changes made to 92d8826ed4.
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)
Make cargo forward pre-existing CARGO if set
Currently, Cargo will always set `$CARGO` to point to what it detects its own path to be (using `std::env::current_exe`). Unfortunately, this runs into trouble when Cargo is used as a library, or when `current_exe` is not actually the binary itself (e.g., when invoked through Valgrind or `ld.so`), since `$CARGO` will not point at something that can be used as `cargo`. This, in turn, means that users can't currently rely on `$CARGO` to do the right thing, and will sometimes have to invoke `cargo` directly from `$PATH` instead, which may not reflect the `cargo` that's currently in use.
This patch makes Cargo re-use the existing value of `$CARGO` if it's already set in the environment. For Cargo subcommands, this will mean that the initial invocation of `cargo` in `cargo foo` will set `$CARGO`, and then Cargo-as-a-library inside of `cargo-foo` will inherit that (correct) value instead of overwriting it with the incorrect value `cargo-foo`. For other execution environments that do not have `cargo` in their call stack, it gives them the opportunity to set a working value for `$CARGO`.
One note about the implementation of this is that the test suite now needs to override `$CARGO` explicitly so that the _user's_ `$CARGO` does not interfere with the contents of the tests. It _could_ remove `$CARGO` instead, but overriding it seemed less error-prone.
Fixes#10119.
Fixes#10113.
Clean up workspace dependencies after cargo remove
### What does this PR try to resolve?
After successful removal of an inherited dependency from a workspace member, clean up the root workspace manifest.
This PR is part of the continued working on cargo remove (#11099, see deferred work).
### How should we test and review this PR?
Make sure the tests cover all possible use cases. After posting this PR, I will post a short self-review regarding some design concerns.
### Additional information
#11194 is currently blocked on this feature.
The bug was `rustflags_from_target` trying to learn rustdocflags from
`target.cfg(…).rustflags`, which is definitely wrong.
As of this writing, either `target.cfg(…).rustdocflags` or
`target.<triple>.rustdocflags` is not supported.
Update the outdated link for rust-semverver
### What does this PR try to resolve?
Update the outdated link for rust-semverver. It works but better to keep it updated.
Only remove fingerprints and build script artifacts of the requested package
Fixes#10069
This is my first PR to cargo. Let me know if you want me to add tests, or if there are any other changes you would like to see :)
This PR changes the globs used to remove fingerprints and build artifacts when running `cargo clean -p <pkid>`. The glob used was `<package_name>-*` which would match artifacts for packages that are prefixed by `<package_name>-` (e.g. `cargo clean -p sqlx` would also remove artifacts for `sqlx-{core,macros,etc.}`). This problem is not seen with other artifacts since those use the crate name instead of package name which normalize hyphens to underscores.
The changes follow the naive approach mentioned in #10069 where some basic string manipulation is done to strip off the last hyphen, hash, and potential extension to get the original package name which can be used to determine if the artifact is actually for the desired package. This means that this **does not** handle trying to resolve the package to determine the artifacts, so it still ignores the url and version that may be passed in the pkgid
Newer anyhow features are required
anyhow doesn't follow semver rules for new features, and Cargo won't compile with anyhow older than this version due to dependence on captured variables in format strings.
Clean stale git temp files
### What does this PR try to resolve?
When cargo is interrupted while libgit2 is indexing the pack file, it will leave behind a temp file that never gets deleted. These files can be very large. This checks for these stale temp files and deletes them.
### How should we test and review this PR?
There is a simulated test here. To test with the actual behavior:
1. Run `CARGO_HOME=chome cargo fetch`
2. While it is "resolving deltas", hit Ctrl-C.
3. Notice that there is a 200MB file in `chome/registry/index/github.com-1ecc6299db9ec823/.git/objects/pack/`
4. Do that several times if you want, each time adds another 200MB file.
5. Build this PR: `cargo b -r`
6. Run `CARGO_HOME=chome CARGO_LOG=cargo::sources::utils=debug ./target/release/cargo fetch`
7. Notice that it deletes the `pack_git2_*` files.
Report crate size on package and publish
### Motivation
Fixes#11251.
This adds a line like `Packaged 42 files, 727.0KiB (143.8KiB compressed)` to the output of `cargo package` and `cargo publish`. See the associated issue for more details.
### Test info
I've updated associated tests to account for the new line in the output, including the file count where relevant. I've also added a few additional tests specifically to address the uncompressed and compressed file sizes.
If you'd like to test this manually, simply run `cargo package` or `cargo publish` within a project of your choice. The new `Packaged` line will appear at the end of the stderr output, or directly before the `Uploaded` line, respectively.
### Review info
This PR touches many test files to account for the additional line of stderr output. For convenience, I've split the PR into 4 commits.
1. contains the actual implementation
2. updates existing tests unrelated to `cargo package` and `cargo publish`
3. updates existing tests related to `cargo package` and `cargo publish`, including file counts where relevant
4. adds new tests specifically for the file sizes, which are generally not covered by existing tests
### Additional information
The feature was discussed [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Report.20crate.20size.20when.20packaging) prior to implementation.
Potential future extensions to explore include:
- Report size per file when using `--verbose`
- Compare to the size of the previously uploaded version to warn if the increase is sufficiently large
- Consider designs that can draw more attention to the most important information
- Warn if large binary files are included ([#9058](https://github.com/rust-lang/cargo/issues/9058))
add a note that some warnings (and/or errors) can be auto-fixed
This adds a note that some warnings (and/or errors) can be auto-fixed by running `cargo --fix`. This only supports `cargo check` as we can't show the same note for `cargo clippy` since it is an external subcommand.
The message for the note was taken from [#10976 (comment)](https://github.com/rust-lang/cargo/issues/10976#issuecomment-1212517765).
