fix(test): Make redactions consistent with snapbox #14790
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I'm unsure how we should be replacing these use cases, so I'm exploring keeping them but making them use snapbox under the hood. Part of the intent of snapbox is that it provides you the building blocks to make what you need.
rustbot
added
A-testing-cargo-itself
epage
force-pushed
the
test-compare
branch
3 times, most recently
from
f807ae9 to
b1ead82
Compare
weihanglo
approved these changes
Nov 7, 2024
epage
force-pushed
the
test-compare
branch
2 times, most recently
from
d09d336 to
a03adcf
Compare
weihanglo
approved these changes
Nov 7, 2024
|
Glad we remove Windows special cases from Cargo! @bors r+ |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
bors
added a commit
that referenced
this pull request
Nov 8, 2024
docs(test): Document Execs assertions based on port effort ### What does this PR try to resolve? Closes #14039 A lot of this was pulled from #14039, common assertions people need to write, and from seeing people not noticing features that exist. I'm leaving behind the `contains` assertions, rather than finding a way to make them work with snapbox. Thankfully, snapbox is designed to let people build their own thing (see #14790). I considered reusing snapbox's `[..]` matches but the code here is pretty minimal, the logic is similar enough, and I don't have a great abstraction for snapbox for it. If there was more of a need, I'd make something work in snapbox. As such, the `contains` assertions are no longer deprecated. While doing this last pass through, I did some polish on the code as well. ### How should we test and review this PR? ### Additional information
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 10, 2024
Update cargo 16 commits in 0310497822a7a673a330a5dd068b7aaa579a265e..4a2d8dc636445b276288543882e076f254b3ae95 2024-11-01 19:27:56 +0000 to 2024-11-09 19:10:33 +0000 - test: adjust `cargo_test_env` to unblock rust submodule update (rust-lang/cargo#14803) - feat(warnings): add build.warnings option (rust-lang/cargo#14388) - Revert "feat: Add `CARGO_RUSTC_CURRENT_DIR`" (rust-lang/cargo#14799) - CI: make the `lint-docs` job required (rust-lang/cargo#14797) - Switch CI from bors to merge queue (rust-lang/cargo#14718) - docs(test): Document Execs assertions based on port effort (rust-lang/cargo#14793) - fix(test): Make redactions consistent with snapbox (rust-lang/cargo#14790) - test(gc): Update remaining unordered tests to snapbox (rust-lang/cargo#14785) - Normalize the `target` paths (rust-lang/cargo#14497) - rustfix: replace special-case duplicate handling with error (rust-lang/cargo#14782) - test: Update some emaining unordered tests to snapbox (rust-lang/cargo#14781) - Change config paths to only check CARGO_HOME for cargo-script (rust-lang/cargo#14749) - Enable transfer feature in triagebot (rust-lang/cargo#14777) - Add transactional semantics to `rustfix` (rust-lang/cargo#14747) - doc: fix `GlobalContext` reference (rust-lang/cargo#14773) - chore: update handlebars to v6, fix build error (rust-lang/cargo#14772)
mati865
pushed a commit
to mati865/rust
that referenced
this pull request
Nov 12, 2024
Update cargo 16 commits in 0310497822a7a673a330a5dd068b7aaa579a265e..4a2d8dc636445b276288543882e076f254b3ae95 2024-11-01 19:27:56 +0000 to 2024-11-09 19:10:33 +0000 - test: adjust `cargo_test_env` to unblock rust submodule update (rust-lang/cargo#14803) - feat(warnings): add build.warnings option (rust-lang/cargo#14388) - Revert "feat: Add `CARGO_RUSTC_CURRENT_DIR`" (rust-lang/cargo#14799) - CI: make the `lint-docs` job required (rust-lang/cargo#14797) - Switch CI from bors to merge queue (rust-lang/cargo#14718) - docs(test): Document Execs assertions based on port effort (rust-lang/cargo#14793) - fix(test): Make redactions consistent with snapbox (rust-lang/cargo#14790) - test(gc): Update remaining unordered tests to snapbox (rust-lang/cargo#14785) - Normalize the `target` paths (rust-lang/cargo#14497) - rustfix: replace special-case duplicate handling with error (rust-lang/cargo#14782) - test: Update some emaining unordered tests to snapbox (rust-lang/cargo#14781) - Change config paths to only check CARGO_HOME for cargo-script (rust-lang/cargo#14749) - Enable transfer feature in triagebot (rust-lang/cargo#14777) - Add transactional semantics to `rustfix` (rust-lang/cargo#14747) - doc: fix `GlobalContext` reference (rust-lang/cargo#14773) - chore: update handlebars to v6, fix build error (rust-lang/cargo#14772)
grovesj005
added a commit
to grovesj005/cargo
that referenced
this pull request
Oct 14, 2025
Auto merge of rust-lang#14793 - epage:test-compare, r=weihanglo docs(test): Document Execs assertions based on port effort ### What does this PR try to resolve? Closes rust-lang#14039 A lot of this was pulled from rust-lang#14039, common assertions people need to write, and from seeing people not noticing features that exist. I'm leaving behind the `contains` assertions, rather than finding a way to make them work with snapbox. Thankfully, snapbox is designed to let people build their own thing (see rust-lang#14790). I considered reusing snapbox's `[..]` matches but the code here is pretty minimal, the logic is similar enough, and I don't have a great abstraction for snapbox for it. If there was more of a need, I'd make something work in snapbox. As such, the `contains` assertions are no longer deprecated. While doing this last pass through, I did some polish on the code as well. ### How should we test and review this PR? ### Additional information
grovesj005
added a commit
to grovesj005/cargo
that referenced
this pull request
Oct 17, 2025
Merge pull request #1 from grovesj005/auto-cargo Auto merge of rust-lang#14793 - epage:test-compare, r=weihanglo docs(test): Document Execs assertions based on port effort ### What does this PR try to resolve? Closes rust-lang#14039 A lot of this was pulled from rust-lang#14039, common assertions people need to write, and from seeing people not noticing features that exist. I'm leaving behind the `contains` assertions, rather than finding a way to make them work with snapbox. Thankfully, snapbox is designed to let people build their own thing (see rust-lang#14790). I considered reusing snapbox's `[..]` matches but the code here is pretty minimal, the logic is similar enough, and I don't have a great abstraction for snapbox for it. If there was more of a need, I'd make something work in snapbox. As such, the `contains` assertions are no longer deprecated. While doing this last pass through, I did some polish on the code as well. ### How should we test and review this PR? ### Additional information
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR try to resolve?
I'm unsure how we should be replacing these use cases, so I'm exploring keeping them but making them use snapbox under the hood. Part of the intent of snapbox is that it provides you the building blocks to make what you need.
If we go this route, we'll still need to un-deprecate and document the assertions.
If we don't go this route, the tests are now more aligned with where they'll eventually be anyways.
Part of #14039
How should we test and review this PR?
Additional information