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 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.
