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`
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.
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).
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
```
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.
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.
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.
Respect `package.rust-version` when generating lockfile, so that
a package with an old MSRV will never get an incompatible lockfile,
even when using the latest Cargo.
Users are still able to edit the `version` field in the lockfile
manually, if they intend to switch to a specific lockfile version.
Fix old_cargos tests
Some of these tests have bitrotted a bit since they aren't enabled by default. The issues are:
* Change to `config` to `config.toml` shouldn't have been made to this test since old cargos can't read config.toml.
* Cargo's own `Carog.toml` now using dotted keys breaks parsing on some old versions, ignore them.
* `cargo pkgid` is now emitting a different format.
* #13085 changed how packages are published in the testsuite to correctly include the `[features]` table in the generated `Cargo.toml`. This exposed an oversight in the `old_cargos::new_features` test wasn't actually testing things correctly. It now correctly illustrates the errors received in older versions. I have a vague memory of this, but I don't remember why it was done this way.
* #10907 changed the default config to use `[registries]` instead of `[source]` to implement source replacement of crates.io. Older versions can't handle that.
Some of these tests probably should just be deleted, since I don't think they are really bringing much value. Or at least they should have some floor that they won't test under. However, I'm not quite ready to do that.
feat: Add hint for adding members to workspace
### What does this PR try to resolve?
Fixes https://github.com/rust-lang/cargo/issues/13403
### How should we test and review this PR?
Reviewd commit by commit
### Additional information
fix: Switch more notes/warnings to lowercase
See https://doc.crates.io/contrib/implementation/console.html#style
By fixing existing cases, we make it more likely people will copy a case they should.
I left out multi-sentence cases because I was unsure how to handle those
