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.
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).
Add global_cache_tracker stability tests.
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.
These tests will be ignored on developer environments if they don't have rustup, or don't have the stable toolchain installed. It does assume that "stable" is at least 1.76. It is required for the tests to run in CI, but will be disabled in rust-lang/rust since it does not have rustup.
I'm not expecting too much trouble with these tests, but if they become too fiddly or broken, they can always be changed or removed.
The support code for running "cargo +stable" is very basic right now. If we expand to add similar tests in the future, then I think we could consider adding support functions (such as [`tc_process`](64ccff290f/tests/testsuite/old_cargos.rs (L21-L36))) to make it easier or more reliable.
fix(cli): Control clap colors through config
### What does this PR try to resolve?
Part of #9012
### How should we test and review this PR?
To accomplish this, I pivoted in how we handle `-C`. In #11029, I made the config lazily loaded. Instead, we are now reloading the config for `-C` like we do for "cargo script" and `cargo install`. If there is any regression, it will be felt by those commands as well and we can fix all together. As this is unstable, if there is a regression, the impact is less. This allowed us access to the full config for getting the color setting, rather than taking more limited approaches like checking only `CARGO_TERM_CONFIG`.
### Additional information
chore: remove the unused function
### What does this PR try to resolve?
Remove the unused function. The code that uses this function has been removed, so it no longer makes sense to keep it.
### How should we test and review this PR?
### Additional information
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).
`CARGO_TARGET_<TRIPLE>_RUSTDOCFLAGS` was accidentally accepted somehow,
so support both config and env officially,
given that removing env support would be a breaking change.
Copy from <https://github.com/rust-lang/cargo/pull/10469#issuecomment-1079503079>:
> I've never been entirely clear why it does this. #4006 didn't really
> explain why it added the corresponding host_dylib_path. I can't envision
> a scenario where it matters. I think compiler plugins and proc-macros
> should load just fine, since libstd.so should already be loaded by the
> compiler. Also, rustc uses rpath these days, and on Windows libstd.so is
> placed in the bin directory which will be searched first anyways.
>
> On balance, I think it should be safe to just remove sysroot_host_libdir.
> I can't come up with a scenario where it matters, at least on
> windows/macos/linux. One issue is that this is most likely to affect
> plugins, but those are deprecated and I think only Servo was the real
> holdout. A concern is that nobody is going to test this use case before
> it hits stable.
Also,
* compiler plugins were removed https://github.com/rust-lang/rust/pull/116412
* servo has moved off from plugins: https://github.com/servo/servo/pull/30508
So should generally be fine.
Fix more redundant imports.
The latest nightly has started warning about redundant imports. This removes those warnings.
Presumably these were casualties of merging between #13464 and #13409.
