tests: Migrate alt_registry to snapbox
### What does this PR try to resolve?
The overall goal is to enable the use of snapshot testing on as many cargo tests as possible to reduce the burden when having to touch a lot of tests. Towards that aim, this PR
- Adds snapshot testing to `cargo_test_support::Execs`
- Migrates `alt_registry` tests over as an example (and to vet it)
I've taken the approach of deprecating all other output assertions on `Execs` with `#[allow(deprecated)]` in every test file. This let's us easily identity what files haven't been migrated, what in a file needs migration, and helps prevent a file from regressing. This should make it easier to do a gradual migration that (as many people as they want) can chip in. It comes at the cost of losing visibility into deprecated items we use. Hopefully we won't be in this intermediate state for too long.
To reduce manual touch ups of snapshots, I've added some regex redactions. My main concern with the `FILE_SIZE` redaction was when we test for specific sizes. That shouldn't be a problem because we don't use `Execs::with_stderr` to test those but we capture the output and have a custom asserter for it.
### How should we test and review this PR?
Yes, this puts us in an intermediate state which isn't ideal but much better than one person trying to do all of this in a single branch / PR.
The main risk is that we'll hit a snag with snapbox being able to support our needs. We got away with a lot because everything was custom, down to the diffing algorithm. This is why I at least started with `alt_registry` to get a feel for what problems we might have. There will likely be some we uncover. I'm fairly confident that we can resolve them in some way,
### Additional information
This is a continuation of the work done in #13980.
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
Previously when checking if a dependency is a proc-macro,
the v2 feature resolve resolver v2 looks for `proc-macro = true`
for every target of the dependency.
However, it's impossible to depend on a non-lib target as a proc-macro.
This fix switches to only check if `proc-macro = true` for `[lib]`
target for a dependency.
fix(toml): remove `lib.plugin` key support and make it warning
### What does this PR try to resolve?
Remove `lib.plugin` key, making it an "unused key" warning.
Remove some of the tests, which should look useless (I hope I'm understanding this
- [x] Remove key, and related tests.
- [x] Adjust the documentation about the plugin.
- [ ] Some of the comments and function names have not yet finished being modified.
part of #13629Closes#13246
fix(toml): Convert warnings that `licence` and `readme` files do not exist into errors
### What does this PR try to resolve?
In this PR:
- Changed the warning to a hard error and modified the associated test function;
- Removed what should have been a redundant test function：`publish::publish_with_missing_readme`；
- Since `cargo publish` is preceded by the execution of `cargo package`, the error message in the test `function bad_license_file` needs to be modified.
issue: https://github.com/rust-lang/cargo/issues/13629#license-file-and-readme-pointing-to-a-non-existent-file.
### Additional information
It seems that this is not enough, the current situation is that `cargo package` warns if `package.readme` is an empty string or the wrong file location, but if I cancel `package.readme`, no warning is generated.
I'm wondering if I should judge `package.readme&licence` when executing `cargo package` and return an error if it doesn't exist?
As this has not been done before, your advice is sought.
test(lints): Ensure unused optional dep fires for shadowed dep
This is a way to have an unused optional dependency before 2024 edition.
In prior editions, it is currently a hard error.
I'm tempted to switch that hard error to this lint in prior editions but at minimum, we need to make sure we don't make changes that cause this to revert back to a hard error on 2024+
This is a way to have an unused optional dependency before 2024
edition.
In prior editions, it is currently a hard error.
I'm tempted to switch that hard error to this lint in prior editions
but at minimum, we need to make sure we don't make changes that cause
this to revert back to a hard error on 2024+
Per discussion in https://github.com/rust-lang/cargo/issues/6790. The
--out-dir CLI option and out-dir config option are often confused with
the OUT_DIR environment variable, when the two serve very different
purposes (the former tells Cargo where to copy build artifacts to,
whereas the OUT_DIR environment variable is set *by* Cargo to tell
build scripts where to place their generated intermediate artifacts).
Renaming the option to something less confusing is a prerequisite to
stabilizing it.
Allows the default git/gitoxide configuration to be obtained from the ENV and config
### What does this PR try to resolve?
The default git/gitoxide feautures config can be obtained througt `-Zgit` and `-Zgitoxide`.
However, it cannot be obtained from environment variables or configurations.
It's not very ergonomic.
### How should we test and review this PR?
The previous commit explained the staus quo, the next commit addressed the problem.
### Additional information
Inspired by https://github.com/rust-lang/cargo/issues/11813#issuecomment-1817517629
See also https://github.com/rust-lang/cargo/issues/13285#issuecomment-2016875459
### Change of usage
1. Mirror Zgit/Zgitoxide when they parsed as string
Specify the feature you like
```
CARGO_UNSABLE_GIT='shallow-deps' cargo fetch
cargo fetch --config "unstable.git='shallow-deps'"
cargo fetch -Zgit="shallow-deps"
```
2. Specify partial fields when parsed as table
```
CARGO_UNSTABLE_GITOXIDE_FETCH=true cargo fetch
```
The rest fields will use Rust default value. That said, checkout and internal_use_git2 will be false.
Besides, you can pass true to the whole feature to specify the pre-defined features.
```
CARGO_UNSTABLE_GITOXIDE=true cargo fetch
```
- pass true to enable all pre-definded git/gitoxide features
- support parse git/gitoxide as table in Config, if the field is tagged with #[serde(default)], then it can be skipped
refactor: Transition direct assertions from cargo-test-support to snapbox
### What does this PR try to resolve?
Cargo has a bespoke testing framework for functional tests
- Extra stuff for us to maintain
- Don't leverage benefits from contributions related to other projects
- Less incentive to be thoroughly documented
UI tests are written using snapbox. The latest release of snapbox (#13963) was geared at supporting cargo's needs in the hope that we can consolidate on testing frameworks.
Besides having a single set of semantics, benefits we'd gain include
- Updating of test snapshots
- Fancier redacting of test output (e.g. #13973)
This is the first incremental step in this direction. This replaces direct assertions with snapbox assertions. This still leaves all of the CLI output assertions. These will be done incrementally.
### How should we test and review this PR?
### Additional information
Fix: Skip deserialization of unrelated fields with overlapping name
### What does this PR try to resolve?
Split from https://github.com/rust-lang/cargo/pull/13687#discussion_r1622694446
This fixes the overlap of environment variable names:
> For example, when env_key is UNSTABLE_GITOXIDE_FETCH
and field_key is UNSTABLE_GIT, the field shouldn't be
added because `unstable.gitoxide.fetch` doesn't
belong to `unstable.git` struct.
### How should we test and review this PR?
Updates of test cases `struct_with_overlapping_inner_struct_and_defaults` can be used to compare changes before and after changes
### Additional information
r? weihanglo and very appreciate your more optimized code
This reverts commit f525e1f383fc0d0a7adbdfb1bac6d6228ae79b33.
This removes color control from warnings for unstable features.
For some reason this removed color support from `cargo -Zhelp` in the
tests but I can't reproduce it locally.
The most important thing was getting the config fix in.
There are two follow ups
- Can we have the config working *and* color?
- Why did this fail for this field and not the others we already had
tests for?
I ran out my immediate time box for looking into these.
Fixes#13991
feat: stabilize `cargo update --precise <yanked>`
### What does this PR try to resolve?
Stabilize `cargo update --precise <yanked>`.
The cargo team has discussed the stabilization in the meeting today.
The interface of this is quite small and not as controversial as `--precise <pre-release>`,
since there is no version requirement operators involved.
We'd like to move forward and stabilize this part.
Note that `--precise <yanked>` allows using yanked version only for the specified package,
We leave the cascading allowing yanked versions (e.g. <https://github.com/rust-lang/cargo/issues/4225#issuecomment-1930353693>) as a future extension.
### How should we test and review this PR?
Check if any adjustment needed for warnings and CLI help text.
### Additional information
cc <https://github.com/rust-lang/cargo/issues/4225>.
Include `lints.rust.unexpected_cfgs.check-cfg` in the fingerprint
### What does this PR try to resolve?
When changing the `--check-cfg` args in the `lints.rust.unexpected_cfgs.check-cfg` lint config, the build should be restarted as the arguments we pass to the compiler change, and they can change the diagnostics output by generating new or removing some `unexpected_cfgs` warning(s).
### How should we test and review this PR?
Look at the before and after test (separate commit).
### Additional information
Similar to https://github.com/rust-lang/cargo/pull/13012 which did that for the declared features.
Contrary to that PR, I didn't add a new `DirtyReason` variant, since even the `[lints]` table didn't get one.
r? `@epage`
chore: Update to snapbox 0.6
### What does this PR try to resolve?
This unblocks regex redactions which will help with `Finished in 3.45s` messages as well as maybe switching away from `compare.rs` generally.
### How should we test and review this PR?
### Additional information
