cargo: Suggest `--nocapture` flag when a test fails with abort
Problem
Consider the following test
#[test]
fn rayon_panic() {
rayon::spawn(|| panic!("o_O"));
loop {}
}
cargo test for it produces the following output:
λ cargo t
Compiling rt v0.1.0 (/home/matklad/tmp/rt)
Finished test [unoptimized + debuginfo] target(s) in 0.17s
Running unittests src/lib.rs (target/debug/deps/rt-fb003f4fc4a43299)
running 1 test
error: test failed, to rerun pass '--lib'
Caused by:
process didn't exit successfully: `/home/matklad/tmp/rt/target/debug/deps/rt-fb003f4fc4a43299` (signal: 6, SIGABRT: process abort signal)
Note how it’s super unclear what exactly failed and why. Passing --nocapture flags helps a bit, but only an expert user would realize that such a flag might be helpful!
λ cargo t -- --nocapture
Finished test [unoptimized + debuginfo] target(s) in 0.01s
Running unittests src/lib.rs (target/debug/deps/rt-fb003f4fc4a43299)
running 1 test
thread '<unnamed>' panicked at 'o_O', src/lib.rs:3:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Rayon: detected unexpected panic; aborting
error: test failed, to rerun pass '--lib'
Caused by:
process didn't exit successfully: `/home/matklad/tmp/rt/target/debug/deps/rt-fb003f4fc4a43299 --nocapture` (signal: 6, SIGABRT: process abort signal)
What happens here is that the test calls std::process::abort. Because, by default, cargo test captures stderr, and because abort doesn’t unwind, libtest doesn’t get a chance to flush stderr. This seems like a fundamental limitation of libtest.
Proposed Solution
It’d be cool if cargo realised that cargo test process was killed with a singnal, and suggested re-running with --nocapture in this case. Note that this won’t always help (it might be the case that a test died without printing anything to stderr), but it doesn’t seem that the note like the following would hurt:
error: test failed, to rerun pass '--lib'
note: test was terminated by the signal, stderr might be truncated, pass `--nocapture` disable output buffering.
Notes
No response
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 19 (19 by maintainers)
Commits related to this issue
- Auto merge of #12463 - stupendoussuperpowers:nocapture_test_msg, r=epage prompt the use of `--nocapture` flag if `cargo test` process is terminated via a signal. Fixes #10855 As per the discussion ... — committed to rust-lang/cargo by bors a year ago
- Auto merge of #12463 - stupendoussuperpowers:nocapture_test_msg, r=epage prompt the use of `--nocapture` flag if `cargo test` process is terminated via a signal. Fixes #10855 As per the discussion ... — committed to rust-lang/cargo by bors a year ago
The two most common libtest harnesses have a
--nocaptureflag but do nothing with itThis is because full
--nocapturesupport requires use of unstable std library features.Especially if you have easy access to the
harnessflag, let’s take advantage of it. Later I want to better define the relationship between cargo and custom test harnesses and when I do, it’ll let us know when a harness supports a standard CLI.Could you create mockups of what you are proposing so we have something more concrete to focus the discussion on?