[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.
test(cli): Verify terminal styling
### What does this PR try to resolve?
This uses a new feature from snapbox that let's us render terminal styling in SVG files. This let's us see / visualize ANSI escape codes, including in github's UI (will render images, including side-by-side images for diffs).
### How should we test and review this PR?
Potential concerns
- assert-rs/trycmd#257: If the snapshot file doesn't exist, you need to `SNAPSHOTS=overwrite` twice
- #9012: because we narrow the enabling of colors to cargo via `CARGO_TERM_COLOR`, clap doesn't know about it and those are rendered without color
- File size: `du -ch tests` reported 13MB before and after
- Loss of information: this doesn't yet include links but we already weren't snapshotting these
- Unconditionally turning on styling and snapshotting for it for all "ui" tests
- Too many SVGs in one PR can negatively affect github's UI
### Additional information
fix(cli): Respect CARGO_TERM_COLOR in '--list' and '-Zhelp'
### What does this PR try to resolve?
Similar to #9012, we aren't respecting `CARGO_TERM_COLOR` for `-Zhelp` and other places. This corrects that.
### How should we test and review this PR?
#9012 was about initialization order to get the value. Here, the problem is that we don't update `Shell` with `CARGO_TERM_COLOR`.
In doing this, I was concerned about keeping track of where it is safe to call `config_configure` without running it twice. To this end, I refactored `main` to make it clear that each call to `config_configure` is in a mutually exclusive path that exists immediately.
### Additional information
Found this with the test for `-Zhelp` in #13461.
Error messages when collecting workspace members now mention the workspace root location
Fixes https://github.com/rust-lang/cargo/issues/13394
### What does this PR try to resolve?
This is a small tweak in error messages for workspaces, with intention to make it easier for users who accidentally created some unwanted workspace and then was surprised by the error coming seemingly out of nowhere. The exact inspiration for the change was [this comment](https://users.rust-lang.org/t/cargo-using-wrong-directory/107126/9?u=cerber-ursi) in discussion on URLO.
### How should we test and review this PR?
This is a simple change in error messages, so the existing test suite should probably be enough. Requests for changing the text further are welcome, of course.
fix(add): Improve error when adding registry packages while vendored
### **What does this PR try to resolve?**
When a vendored directory is established, cargo add no longer adds new packages. Instead, it tries to translate a package name into a package that already exists in the vendored directory.
[More details](https://github.com/rust-lang/cargo/issues/10729#issue-1260548746)
Since `@epage` has done most of the work, here I do the rest of the finishing work.
Improves the error from #10729
### **How should we test and review this PR?**
The implementation procedure is as follows:
https://github.com/rust-lang/cargo/issues/10729#issuecomment-1191633351
Test steps：
1. Try to get an arbitrary crate and execute `cargo vendor` command.
2. Configure the vendor directory in .cargo/config.toml.
3. Add `alter-registry` to the config.toml file.
```
[registries]
alter-registry= { index = "XXX" }
```
4. run the same `cargo add` command.
```
cargo add another-crate --registry alter-registry
```
[docs]:Add missing jump links
### What does this PR try to resolve?
Add missing jump links.
If the maintainer does this intentionally, close the PR at any time.
