This is a partial revert of ##14121
(e11d1722bb6e1e58c91adb1964993c74b45f4293)
Our focus for redacting (auto or with globs) includes
- run-specific information (timing, hashes, platform-specific wording)
- rustc-specific information
(We tend to use globs for rustc-specific information because there might
be some very specific times we need to care about some of the details)
However, "Packaged files" does not fit into any of that and, for now, we
are erring on the side of redacting less, rather than more, with the
move to snapbox.
As we see how it works out and what the underlying requirements are, we
can revisit this.
test: Auto-redact file number
This is from <https://github.com/rust-lang/cargo/pull/14096#discussion_r1648889843>.
Although the number of files in `cargo package` is important,
we have `validate_crate_contents` and `validate_upload_with_contents`
that verify the exact contents.
Redacting `Packaged` status should be fine.
Add `CodeFix::apply_solution` and impl `Clone`
### What does this PR try to resolve?
In Clippy we have a good few lints that produce mutually exclusive suggestions e.g.
```
error: octal-looking escape in a literal
--> tests/ui/octal_escapes.rs:6:19
|
LL | let _bad2 = b"\033[0m";
| ^^^^
|
help: if an octal escape is intended, use a hex escape instead
|
LL | let _bad2 = b"\x1b[0m";
| ~~~~
help: if a null escape is intended, disambiguate using
|
LL | let _bad2 = b"\x0033[0m";
| ~~~~~~
```
For these we have to disable rustfix tests since the suggestions are overlapping, this PR adds a method to `rustfix` that `ui_test` could use in order to produce multiple `.fixed` files, one for each alternative suggestion
### Additional information
It does not work for for multiple suggestions coming from a single subdiagnostic ([`Diag::span_suggestions`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/diagnostic/struct.Diag.html#method.span_suggestions)) e.g.
```
help: consider importing one of these items
|
1 + use std::collections::HashMap;
|
1 + use ahash::HashMap;
```
Solving this would be blocked on https://github.com/rust-lang/rust/issues/53934, on the Clippy side we only have one use of `span_suggestions` however so it's still very useful without this
The test cases use Clippy lints that I generated by setting the `parse_and_replace` test to use `clippy-driver` because of familiarity, if there's a rustc case that does multiple suggestions it would be good to go with that
Add local registry overlays
This PR adds (private to cargo internals) support for local registry overlays, in which you can locally pretend to add packages to remote registries; the local packages will have the same source ids as the remote registry that you're overlaying.
There are two ways to set up these overlays: programmatically using `GlobalContext::local_overlays` and through the `__CARGO_TEST_PACKAGE_CONFUSION_VULNERABILITY_DO_NOT_USE_THIS` environment variable. You can't set up these overlays with `.cargo/config`.
The motivation for this is [packaging workspaces](https://github.com/rust-lang/cargo/issues/10948). When we're packing a workspace, we'd like to be able to pretend (for lockfile generation and verification) that some workspace packages are already published even though they aren't.
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.
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
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
