Fix some test output validation.
A bunch of these tests weren't testing what they claimed to. For some reason, a bunch of them were checking for cargo's output with `.with_stdout("")`, but since cargo almost never prints to stdout, that doesn't actually validate the test. Most of these are checking that cargo doesn't recompile when run a second time, and in those cases it should be checking that there is a single line of output ("Finished"). I don't know the history here, many of these tests were before my time, perhaps cargo did use to print something to stdout? Or perhaps it was a long run of bad copy-and-paste.
There were a few other tests that were checking `with_stdout("")` for no apparent reason. I switched those to check the stderr output.
docs(ref): Find a place to comment on --cap-lints
Looking over the points of confusion highlighted in #5998, one is in rustc which is agnostic of any of this policy and the rest are in historical documents.
Inspired by previous comments, I figured we could fit this into a discussion of `[lints]` by talking about the scope of the feature.
Fixes#5998
Switch from AtomicU64 to Mutex.
Not all platforms support AtomicU64, so this swaps the usage with Mutex. The difference in performance should be imperceptible.
If the only path is a loop then counted as the shortest path.
This is a fix for #12941
This graph data structure is used to store dependency DAGs. Where each edge represents a dependency from a package to the package that fulfilled the dependency. Different parts of the resolver store this data in opposite directions, sometimes packages point at the things that depend on them other times packages point to the parents that required them. Error messages often need to report on why a package is in the graph, either by walking up toward parents or down toward children depending on how this graph is stored. #12678 unified the two different walking implementations, and replace them with a breadth first search so as to find the shortest path. This code ignored when edge pointed at a package that had already been reached, because that generally describes a longer path to an existing package.
Unfortunately, when I said this was a DAG that was a simplification. There can be cycles introduced as dev-dependencies. The existing code would reasonably ignore the cycles figuring that if we continue searching we would eventually find the root package (a package that nothing depended on). Missing the possibility that the root package created the cycle.
Now we search through the entire graph looking for a root package. If we do not find a root package we report the path to the last package we processed.
fix(resolver): Prefer MSRV, rather than ignore incompatible
### What does this PR try to resolve?
This is another experiment for #9930.
Comparing preferring over exclusively using MSRV compatible:
Benefits
- Better error messages
- `--ignore-rust-version` is implicitly sticky
Downsides
- Can't backtrack for MSRV compatible version
- Still requires workspace-wide MSRV (compared to our desired end state of declaring MSRV as yet another dependency)
### How should we test and review this PR?
### Additional information
Note: `--ignore-rust-version` is not yet implemented for the resolver.
This builds on #12930
This is another experiment for #9930.
Comparing preferring over exclusively using MSRV compatible:
Benefits
- Better error messages
- `--ignore-rust-version` is implicitly sticky
Downsides
- Can't backtrack for MSRV compatible version
- Still requires workspace-wide MSRV (compared to our desired end state of declaring MSRV as yet another dependency)
This builds on #12930
Looking over the points of confusion highlighted in #5998,
one is in rustc which is agnostic of any of this policy and the rest are
in historical documents.
Inspired by previous comments, I figured we could fit this into a
discussion of `[lints]` by talking about the scope of the feature.
Fixes#5998
fix error message for duplicate links
Fixing an error message which is both misformatted and contains the wrong text.
Previously it said that only one crate in the tree should use `links ='linking-crate'`; now it says that only one crate should use `links = 'linked-library'`
Only filter out target if its in the package root
### What does this PR try to resolve?
Only filter out target if its in the package root. Fixed https://github.com/rust-lang/cargo/issues/12790
### How should we test and review this PR?
Add two testcase in tests/testsuite/package.rs for this PR.
- `include_files_called_target_project` testcase test the logic for none git repository. By the way, our PR was based on git repository, so this testcase was a little irrelevant.
- `include_files_called_target_git` testcase was made for git repository. There are two cases here, one is the target in the uncommitted state, at this time should not be included, and one is the target in the committed state, at this time should be included
### Additional information
Ignore changing_spec_relearns_crate_types on windows-gnu
This disables the `custom_target::changing_spec_relearns_crate_types` on windows-gnu targets for the same reason as #12763. The update to LLVM 17 has started to cause lld to crash when using a custom target. cc https://github.com/rust-lang/rust/issues/115985
I surveyed the rest of the testsuite, and I don't see any other tests that perform linking with custom targets.
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.
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
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.
