You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With rust-lang/rust#133073, we decided to rename --nocapture but overlooked RUST_TEST_NOCAPTURE. I suggested we defer how to handle RUST_TEST_NOCAPTURE to not block --no-capture on bigger decisions.
Options
Add RUST_TEST_NO_CAPTURE
Switch to positive logic with RUST_TEST_CAPTURE
Maybe re-evaluate the true/false condition
Deprecate it
The text was updated successfully, but these errors were encountered:
Thinking more on this, I'm leaning towards "defer".
--no-capture is a nice quality of life improvement that I'd rather not block on "bigger questions". For me, the big question I'm starting to wonder about is if we should deprecate the env variables. My suspicion is that they are a low-effort config system that is meant to make up for a lacking in the common test runner (cargo test). In that case, we should instead focus on the common test runner. These could also cause problems as Cargo tries to coordinate the behavior of test binaries. If cargo test is trying to read json output and the user bypasses cargo to tell the test to report other content, that could become problematic.
So this feels like its subject to path dependence. libtest inherited env variable support and then tweaked it. Without further information, I'm guessing RUST_TEST_NOCAPTURE just then copied that pattern.
With rust-lang/rust#133073, we decided to rename
--nocapture
but overlookedRUST_TEST_NOCAPTURE
. I suggested we defer how to handleRUST_TEST_NOCAPTURE
to not block--no-capture
on bigger decisions.Options
The text was updated successfully, but these errors were encountered: