Skip to content

--quiet propagation is unavailable to custom test harnesses #15465

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
kpreid opened this issue Apr 29, 2025 · 1 comment
Open

--quiet propagation is unavailable to custom test harnesses #15465

kpreid opened this issue Apr 29, 2025 · 1 comment
Labels
A-cli Area: Command-line interface, option parsing, etc. C-enhancement Category: enhancement Command-test S-needs-rfc Status: Needs an RFC to make progress.

Comments

@kpreid
Copy link
Contributor

kpreid commented Apr 29, 2025

Currently, Cargo will forward the --quiet option from its command line to test binaries. However, it does not do this when harness = false.

if unit.target.harness() && gctx.shell().verbosity() == Verbosity::Quiet {
cmd.arg("--quiet");
}

This means that test targets with custom test harnesses cannot replicate the automatic coordination the rustc test harness gets. Given the stated plans to promote custom test harnesses over adding more features to libtest, I believe this behavior needs to be revised.

I think it is likely that the correct solution here is to add some larger API for more structured, extensible communication between cargo and a custom test harness, rather than changing what individual args are sent. Still, I’m filing this issue to make sure this is considered and to document the quirk for anyone else who is writing a libtest-compatible harness and debugging why their output stays verbose.

@rustbot label +Command-test +A-cli

@rustbot rustbot added A-cli Area: Command-line interface, option parsing, etc. Command-test labels Apr 29, 2025
@epage epage added C-enhancement Category: enhancement S-needs-rfc Status: Needs an RFC to make progress. labels Apr 30, 2025
@epage
Copy link
Contributor

epage commented Apr 30, 2025

Over time, we expect to tighten the relationship between cargo test and libtest further (e.g. using the json output). Cargo will need some way of knowing a custom test harnesses capabilities.

Some options include

  • Some field on the build-target table to specify a version of the cargo/libtest protocol
  • Name the custom test harness (<target>.test = "dep:libtest2") and allow the custom test harness' package to specify the cargo/libtest protocol it implements

Either way, we'll need a way to set this across the entire package, instead of hand-enumerating every target (#6945).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cli Area: Command-line interface, option parsing, etc. C-enhancement Category: enhancement Command-test S-needs-rfc Status: Needs an RFC to make progress.
Projects
Status: No status
Development

No branches or pull requests

3 participants