Skip to content

libtest: expose --fail-fast as an unstable command-line option #142807

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

sourcefrog
Copy link
Contributor

@sourcefrog sourcefrog commented Jun 20, 2025

This exposes the fail_fast option added in #105153 on the test harness command line, so that workflows that only want to know if any test fails can find out without waiting for everything to run. For example, cargo-mutants just needs to know if any tests fails. It only works with -Zunstable-options.

(Probably I should make an issue to stabilize it but I just wanted to see if the core change is OK, first.)

@rustbot
Copy link
Collaborator

rustbot commented Jun 20, 2025

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 20, 2025
@sourcefrog
Copy link
Contributor Author

I can not yet find any in-tree tests for the libtest command line options...

@sourcefrog
Copy link
Contributor Author

I locally tested this with rustup toolchain link, and the basic function works as intended: after one test fails, no other tests start.

However that does find a problem that doctests don't accept this option.

@jieyouxu
Copy link
Member

cc @rust-lang/testing-devex
r? libs-api (libtest cli)

@rustbot rustbot added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jun 20, 2025
@rustbot rustbot assigned dtolnay and unassigned SparrowLii Jun 20, 2025
@jieyouxu jieyouxu added A-libtest Area: `#[test]` / the `test` library T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. T-testing-devex Relevant to the testing devex team (testing DX), which will review and decide on the PR/issue. and removed T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 20, 2025
@epage
Copy link
Contributor

epage commented Jun 20, 2025

Over at rust-lang/testing-devex-team#5, we're building up a list of all of the problems with the current doctest architecture.

I've noted this for the next testing-devex meeting.

@epage
Copy link
Contributor

epage commented Jun 20, 2025

As this builds on the original implementation and it was recognized as a hack by both the reviewer and the implementer, it would be good to get their feedback. My main concern is I've found PRs a poor place for collecting requirements / design information because they can come and go as different people work on it or even with the same author. Unsure if we should go ahead and do that discussion here or open an issue.

@jieyouxu
Copy link
Member

(It's probably best as its own issue, PR discussions are very easy to become lost)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-libtest Area: `#[test]` / the `test` library S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. T-testing-devex Relevant to the testing devex team (testing DX), which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants