feat(toml): Warn on unset Edition
### What does this PR try to resolve?
On [Internals](https://internals.rust-lang.org/t/idea-rustc-cargo-should-warn-on-unspecified-edition/20309), the idea came up for warning on unset Edition.
Besides helping people who forget to set the Edition, this creates symmetry between `Cargo.toml` and cargo scripts (#12207). While the default is different in each case, we are making the default obvious and guiding people away from it.
### How should we test and review this PR?
There are separate commits for adding tests (and refactors) so the changes in behavior will be more obvious
### Additional information
This builds on
- #13499
- #13504
fix(msrv): Report all incompatible packages, not just a random one
### What does this PR try to resolve?
In #9930, it recommended improving the error for incompatible packages
so people can better get to the root of the problem.
For example, you might get an error about `clap_lex` but resolving the
error for the higher level `clap` could make the problem with `clap_lex`
go away.
Because I generally saw earlier packages in the graph reported, I
assumed we were reporting these errors bottom up.
It turns out, we are reporting them in the `UnitGraph`s order, which is
non-deterministic because it is built on a `HashMap`.
So this adds determinism and shows all incompatible dependencies
(not just the bottom or the root).
### How should we test and review this PR?
This is a first step.
We might find that we still want to only include the shallowest units,
rather than all.
At that point, we can add the complexity to address this by walking the
unit graph.
We could also further improve this by querying the index to suggest
compatible versions of packages.
The multi-package test wasn't split out into its own commit because hat would have required fixing the non-determinism one way to then just revert it when we fix it this way.
### Additional information
In #9930, it recommended improving the error for incompatible packages
so people can better get to the root of the problem.
For example, you might get an error about `clap_lex` but resolving the
error for the higher level `clap` could make the problem with `clap_lex`
go away.
Because I generally saw earlier packages in the graph reported, I
assumed we were reporting these errors bottom up.
It turns out, we are reporting them in the `UnitGraph`s order, which is
non-deterministic because it is built on a `HashMap`.
So this adds determinism and shows all incompatible dependencies
(not just the bottom or the root).
This is a first step.
We might find that we still want to only include the shallowest units,
rather than all.
At that point, we can add the complexity to address this by walking the
unit graph.
We could also further improve this by querying the index to suggest
compatible versions of packages.
[docs]: Clarify vendored sources as read-only and way to modify
What does this PR try to resolve?
To document that vendored sources are not intended to be modified, and `[patch]` or a `path` dependency is the correct way to modify a vendored crate.
https://github.com/rust-lang/cargo/issues/5805#issuecomment-1868049928
refactor: Clarify more Config -> Context
### What does this PR try to resolve?
This is a follow up to #13409 and #13486
### How should we test and review this PR?
### Additional information
test: Make `edition` explicit in packages
### What does this PR try to resolve?
This ensures we don't rely on the edition default for manifests, unblocking the door for warning on unset editions.
### How should we test and review this PR?
### Additional information
Alternatives considered
- Augment test output for the new warnings: figured we'd want tests closer to our intention and this seemed more work to update everything
- Make a builder API for generating manifests, allowing us to change the default in one place. Still an interesting idea but a lot of work for this one change.
Risks
- I missed that a test was specifically for unset edition but that is unlikely of a case to come up
Add all unit's children recursively for `doc.extern-map` option
Fixes https://github.com/rust-lang/rust/issues/120993.
It allows to fix link generation of reexport of foreign items when deps documentation is not generated. Sometimes, we need to have information about not only direct dependencies but also of dependencies of these direct dependencies and so on.
Silently ignore `cargo::rustc-check-cfg` to avoid MSRV annoyance when stabilizing `-Zcheck-cfg`
This PR, removes the warning when trying to use `cargo::rustc-check-cfg` on stable or nightly (without the nightly-only `-Zcheck-cfg` flag) to avoid MSRV annoyance when stabilizing `-Zcheck-cfg`.
See this [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/check-cfg.20backwards.20compatible.20warnings) for more information and context.
cc `@ehuss`
feat: Add "-Zpublic-dependency" for public-dependency feature.
### What does this PR try to resolve?
Part of https://github.com/rust-lang/cargo/issues/13308, include:
- Switching the cargo-features to a -Z
- Warning if public is used without -Z and setting it to false
These had not done yet:
- We should also warn if the data type changes but that is less likely to happen and could possibly be skipped
- Ensuring the published version of the package does not have public
### How should we test and review this PR?
All test case should be pass.
### Additional information
r? `@epage`
Stabilize global cache data tracking.
This stabilizes the global cache last-use data tracking. This does not stabilize automatic or manual gc.
Tracking issue: https://github.com/rust-lang/cargo/issues/12633
## Motivation
The intent is to start getting cargo to collect data so that when we do stabilize automatic gc, there will be a wider range of cargo versions that will be updating the data so the user is less likely to see cache misses due to an over-aggressive gc.
Additionally, this should give us more exposure and time to respond to any problems, such as filesystem issues.
## What is stabilized?
Cargo will now automatically create and update an SQLite database, located at `$CARGO_HOME/.global-cache`. This database tracks timestamps of the last time cargo touched an index, `.crate` file, extracted crate `src` directory, git clone, or git checkout. The schema for this database is [here](a7e9347926/src/cargo/core/global_cache_tracker.rs (L233-L307)).
Cargo updates this file on any command that needs to touch any of those on-disk caches.
The testsuite for this feature is located in [`global_cache_tracker.rs`](a7e9347926/tests/testsuite/global_cache_tracker.rs).
## Stabilization risks
There are some risks to stabilizing, since it commits us to staying compatible with the current design.
The concerns I can think of with stabilizing:
This commits us to using the database schema in the current design.
The code is designed to support both backwards and forwards compatible extensions, so I think it should be fairly flexible. Worst case, if we need to make changes that are fundamentally incompatible, then we can switch to a different database filename or tracking approach.
There are certain kinds of errors that are ignored if cargo fails to save the tracking data (see [`is_silent_error`](64ccff290f/src/cargo/core/global_cache_tracker.rs (L1796-L1813))).
The silent errors are only shown with --verbose. This should help deal with read-only filesystem mounts and other issues. Non-silent errors always show just a warning. I don't know if that will be sufficient to avoid problems.
I did a fair bit of testing of performance, and there is a bench suite for this code, but we don't know if there will be pathological problems in the real world. It also incurs an overhead that all builds will have to pay for.
I've done my best to ensure that this should be reliable when used on network or unusual filesystems, but I think those are still a high-risk category. SQLite should be configured to accommodate these cases, as well as the extensive locking code (which has already been enabled).
A call for public testing was announced in December at https://blog.rust-lang.org/2023/12/11/cargo-cache-cleaning.html. At this time, I don't see any issues in https://github.com/rust-lang/cargo/labels/Z-gc that should block this step.
While we can just bump to the latest versions, this time we do a
conservative one for some crates.
* `cargo-util` --- 0.2.10 to 0.2.11 contain only comment changes.
* `cargo-platform` --- 0.1.6 to 0.1.8 contain only lint and metadata changes
chore: fixed a typo(two->too)
### What does this PR try to resolve?
typo: `for two long` corrected by `for too long`
### How should we test and review this PR?
### Additional information
HACK: `rustdoc --test` not only compiles but executes doctests.
Ideally only execution phase should have search paths appended,
so the executions can find native libs just like other tests.
However, there is no way to separate these two phase, so this
hack is added for both phases.
