I'm intentionally being light as I want to pull in a lot of "lessons
learned" from the port to snapbox into the docs and want that as a
dedicated PR to make it easier for the contributors to that effort to
review it.
fix(test)!: Clarify extension trait role with rename
When browsing the docs, I feel like this will make it easier to tell the role of these traits within the API.
Or in other words, I can easily tell that these fill a support role and for what, so I know when I care to look into them.
We use this naming pattern for
`cargo_test_support::paths::CargoPathExt`.
When browsing the docs, I feel like this will make it easier to tell the
role of these traits within the API.
Or in other words, I can easily tell that these fill a support role and
for what, so I know when I care to look into them.
We use this naming pattern for
`cargo_test_support::paths::CargoPathExt`.
fix(test): Move path2url to CargoPathExt::to_url
### What does this PR try to resolve?
This is a small step, like #14243, to improve the clarity of `cargo-test-support`s API.
Overall, I'm trying to make it more obvious on https://docs.rs/cargo-test-support/latest/cargo_test_support/ which items to reach for when. I figured this is one that could be demoted to `paths` When doing so, I noticed `CargoPathExt`. I figured if we had any extension traits for `Path`, then this is a
reasonable one to add.
### How should we test and review this PR?
### Additional information
I was considering moving this into `paths` and noticed `CargoPathExt`.
I figured if we had any extension traits for `Path`, then this is a
reasonable one to add.
test：migrate `doc/directory/docscrape` to snapbox
### What does this PR try to resolve?
Complete the following file migration:
```
tests/testsuite/directory.rs
tests/testsuite/doc.rs
tests/testsuite/docscrape.rs
```
part of #14039
`cargo clean` shows file size without fraction in summary when the size
is lower than 1024. And we need to avoid matching things like `%2B%23..`
found in other test cases, the trailing `\s` is added to regex.
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
