query{_vec} use IndexSummary
This builds on the work from https://github.com/rust-lang/cargo/pull/12749 and the discussion of the overall approach is at https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/better.20error.20messages.20for.20filtered.20versions.2E
### What does this PR try to resolve?
Changing the two traits `Registry` and `Source` to use the new `IndexSummary' involves a lot of changes all throughout the code base. This would be hard to review if it also included any logic changes. So this PR is just adding the type to the trait and immediately unwrapping every place it is used.
The hope is that reviewing changes to logic/ergonomics will be easier to review once the mechanical changes have been merged.
### How should we test and review this PR?
This is an internal re-factoring and all the tests still pass.
The config.toml file in rust-lang/rust has the omit-git-hash option,
which prevents git information from being embedded into binaries. This
works for most tools, as they rely on the git information provided by
bootstrap through environment variables.
Cargo does its own git detection in its build script though, which
didn't adhere to to that option. This changes that by skipping git
detection whenever bootstrap signals the option is enabled.
Fix --quiet being used with nested subcommands.
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.
As for this diff, the help text changes because the `--quiet` flag is changing position (except for the 3 commands mentioned above where it is now added).
Fixes#12957
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
make some debug assertion failures more informative
In https://github.com/rust-lang/miri/issues/3160, we got a report of a user running into an assertion failure in cargo. Unfortunately the failure message is not very informative. This PR hopefully makes that failure easier to debug.
refactor(toml): Consistently lead with 'Toml' prefix
### What does this PR try to resolve?
Like with #12954, I noticed this inconsistency while working towards #12801 and wanted to fix it.
### How should we test and review this PR?
### Additional information
refactor(toml): Remove unused method
### What does this PR try to resolve?
While finding better homes for logic for #12801, I found this part of the workspace-inheritance trait was unused.
### How should we test and review this PR?
### Additional information
`Workspace` and `MaybeWorkspace` doesn't make the intent as clear.
Generally when talking about this, we say that it "inherits".
This also better matches the terms in `cargo_toml` and `cargo-manifest`
packages.
Fix non-deterministic behavior in last-use repopulation
This fixes an issue where some last-use tests would fail sporadically because the code that populates missing database entries was using the current time as it was iterating over the files. If the clock happened to roll over while it was iterating, then different files would get different timestamps non-deterministically.
The fix is to snapshot the current time when it starts, and reuse that time while repopulating. I didn't do this originally just because I was reluctant to pass yet another argument around. However, it seems like this is necessary. In #12634, we discussed other options such as having some kind of process-global "now" snapshot (like in `Config`), but I'm reluctant to do that because I am uneasy dealing with long-lived programs, or handling before/after relationships (like different parts of the code not considering that all timestamps might be equal). It might be something that we could consider in the future, but I'm not sure I want to try right now.
This fixes an issue where some last-use tests would fail sporadically
because the code that populates missing database entries was using the
current time as it was iterating over the files. If the clock happened
to roll over while it was iterating, then different files would get
different timestamps non-deterministically.
The fix is to snapshot the current time when it starts, and reuse that
time while repopulating. I didn't do this originally just because I was
reluctant to pass yet another argument around. However, it seems like
this is necessary. In #12634, we discussed other options such as having
some kind of process-global "now" snapshot (like in `Config`), but I'm
reluctant to do that because I am uneasy dealing with long-lived
programs, or handling before/after relationships (like different parts
of the code not considering that all timestamps might be equal). It
might be something that we could consider in the future, but I'm not
sure I want to try right now.
Add cache garbage collection
### What does this PR try to resolve?
This introduces a new garbage collection system which can track the last time files were used in cargo's global cache, and delete old, unused files either automatically or manually.
### How should we test and review this PR?
This is broken up into a large number of commits, and each commit should have a short overview of what it does. I am breaking some of these out into separate PRs as well (unfortunately GitHub doesn't really support stacked pull requests). I expect to reduce the size of this PR if those other PRs are accepted.
I would first review `unstable.md` to give you an idea of what the user side of this looks like. I would then skim over each commit message to give an overview of all the changes. The core change is the introduction of the `GlobalCacheTracker` which is an interface to a sqlite database which is used for tracking the timestamps.
### Additional information
I think the interface for this will almost certainly change over time. This is just a stab to create a starting point where we can start testing and discussing what actual user flags should be exposed. This is also intended to start the process of getting experience using sqlite, and getting some testing in real-world environments to see how things might fail.
I'd like to ask for the review to not focus too much on bikeshedding flag names and options. I expect them to change, so this is by no means a concrete proposal for where it will end up. For example, the options are very granular, and I would like to have fewer options. However, it isn't clear how that might best work. The size-tracking options almost certainly need to change, but I do not know exactly what the use cases for size-tracking are, so that will need some discussion with people who are interested in that.
I decided to place the gc commands in cargo's `cargo clean` command because I would like to have a single place for users to go for deleting cache artifacts. It may be possible that they get moved to another command, however introducing new subcommands is quite difficult (due to shadowing existing third-party commands). Other options might be `cargo gc`, `cargo maintenance`, `cargo cache`, etc. But there are existing extensions that would interfere with.
There are also more directions to go in the future. For example, we could add a `cargo clean info` subcommand which could be used for querying cache information (like the sizes and such). There is also the rest of the steps in the original proposal at https://hackmd.io/U_k79wk7SkCQ8_dJgIXwJg for rolling out sqlite support.
See #12633 for the tracking issue
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.
