This renames the gc config table to `[cache]` to help avoid some
confusion, and to set up a namespace for possible expansion in the
future for different kind of cache controls.
Low-level settings are stuffed into the `[cache.global-clean]` table,
but we do not expect to stabilize these at this time. Only the top-level
`cache.auto-clean-frequency` setting is expected to be stabilized.
Closes https://github.com/rust-lang/cargo/issues/14292
This makes the cache tracking synchronization code resilient to
unexpected files in the cache directory. Previously the code was
assuming that all entries in paths like `registry/index/*` are
directories. However, in circumstances like opening the directories in
macOS's finder, that can create files called `.DS_Store`. This caused it
to fail to scan within that path, since it isn't a directory.
This could in theory be made stricter, such as expecting directories to
have a particular pattern for its name. However, it seems like we never
enacted restrictions on what names are used for the git directories, so
it wouldn't work very well for that. Though that is something we could
consider in the future.
This helps `-Ztrim-paths` build a stable cross-platform path for the
registry and git sources. Sources files then can be found from the same
path when debugging.
It also helps cache registry index all at once for all platforms,
for example the use case in rust-lang/cargo#14795
(despite they should use `cargo vendor` instead IMO).
Some caveats:
* Newer cargo will need to re-download files for global caches
(index files, git/registry sources).
The old cache is still kept and used when running with older cargoes.
* Windows is not really covered by the "cross-platform" hash,
because path prefix components like `C:` are always there.
That means hashes of some sources kind,
like local registry and local path,
are not going to be real cross-platform stable.
There might be hash collisions if you have two registries under the same
domain. This won't happen to crates.io, as the infra would have to
intentionally put another registry on index.crates.io to collide.
We don't consider this is an actual threat model, so we are not going to
use any cryptographically secure hash algorithm like BLAKE3.
See also <https://github.com/rust-lang/cargo/issues/13171#issuecomment-2181465128>
This was mostly done by clippy via `clippy::doc_markdown`.
I then reviewed it to fix words that shouldn't have it or where `--fix`
put the backtick in the wrong location.
This is for `cargo generate-lockfile` and when syncing the lockfile with
the manifest.
We still show it for `cargo update` because of `cargo update
--workspace`.
We hacked around this previously by filtering out the `num_pkgs==1` case
for single packages but this didn't help with workspaces.
This builds on the prior work to consolidate everything, simplifying the
code and making it clearer what behavior differences exist between
change kinds.
fix(test): Move path2url to CargoPathExt::to_url
### What does this PR try to resolve?
This is a small step, like #14243, to improve the clarity of `cargo-test-support`s API.
Overall, I'm trying to make it more obvious on https://docs.rs/cargo-test-support/latest/cargo_test_support/ which items to reach for when. I figured this is one that could be demoted to `paths` When doing so, I noticed `CargoPathExt`. I figured if we had any extension traits for `Path`, then this is a
reasonable one to add.
### How should we test and review this PR?
### Additional information
We now include the prelude in so many places, this simplifies how we can
present how `cargo-test-support` works.
Yes, this included some `use` clean ups but its already painful enough
walking through every test file, I didn't want to do it twice.
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
Cargo likes to modify PATH, which circumvents the ability to choose the
correct "cargo" executable to run on Windows (because Windows uses PATH
for both binary and shared library searching).
This adds some tests to ensure that the database used in the global
cache tracker stays compatible across versions. These tests work by
using rustup to run both the current cargo and the stable cargo, and
verifying that when switching versions, everything works as expected.
This fixes an issue where `--quiet` doesn't work with commands that have
subcommands. This is because `config_configure` only looks at the global
and top-level subcommand, and not deeper subcommands. The issue was that
`--quiet` was not defined as a global flag. This was changed in
https://github.com/rust-lang/cargo/pull/6358 in order to give a better
help message for `cargo test --quiet`. I don't remember if clap just
didn't support overriding at the time, or if we just didn't know how it
worked. Anyways, it seems to work to override it now, so I think it
should be fine to mark it as global.
This should bring in `--quiet` more in-line with how `--verbose` works.
This means that `--quiet` is now accepted with `cargo report`,
`cargo help`, and `cargo config`.
This also fixes `--quiet` with `cargo clean gc`.
This should also help with supporting `--quiet` with the new `cargo
owner` subcommands being added in
https://github.com/rust-lang/cargo/pull/11879.
Fixes#12957
This was requested to separate the interaction of `cargo clean` and the
cleaning of global cache data, and to minimize the impact of this
initial implementation.
This adds a garbage collector which will remove old files from cargo's
global cache.
A general overview of the changes here:
- `cargo::core::global_cache_tracker` contains the `GlobalCacheTracker`
which handles the interface to a sqlite database which stores
timestamps of the last time a file was used.
- `DeferredGlobalLastUse` is a type that implements an optimization for
collecting last-use timestamps so that they can be flushed to disk all
at once.
- `cargo::core::gc` contains the `Gc` type which is the interface for
performing garbage collection. It coordinates with the
`GlobalCacheTracker` for determining what to delete.
- Garbage collection can either be automatic or manual. The automatic
garbage collection supports some config options for defining when
it runs and how much it deletes.
- Manual garbage collection can be performed via options to `cargo
clean`.
- `cargo clean` uses the new package cache locking system to coordinate
access to the package cache to prevent interference with other cargo
commands running concurrently.
