fix(test): Expose '--no-capture' in favor of --nocapture by epage · Pull Request #139224 · rust-lang/rust (original) (raw)

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

[ Show hidden characters]({{ revealButtonHref }})

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

Apr 1, 2025

Comment on lines +202 to +204

epage 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.

labels

Apr 1, 2025

rustbot added A-compiletest

Area: The compiletest test runner

A-testsuite

Area: The testsuite used to check the correctness of rustc

T-bootstrap

Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

labels

Apr 10, 2025

epage changed the titlefix(test): Expose '--no-capture', deprecating '--nocapture' fix(test): Expose '--no-capture' in favor of --nocapture

Apr 10, 2025

epage added I-libs-api-nominated

Nominated for discussion during a libs-api team meeting.

and removed T-bootstrap

Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

labels

Apr 14, 2025

This will help with hiding some options in --help

This improves consistency with commonly expected CLI conventions, avoiding a common stutter people make when running tests (trying what they expect and then having to check the docs to then user whats accepted).

An alternative could have been to take a value, like --capture <value> (e.g. pytest does this). Overall, we're shifting focus for features to custom test harnesses (see rust-lang#134283). Most of pytests modes will likely be irrelevant in that situation. As for the rest, its too early to tell which, if any, may be relevant, so we're sticking with this small, quality of life improvement.

By deprecating --nocapture, we intend that custom test harnesses do not need to support it for reasons outside of their own compatibility requirements, much like the deprecation in rust-lang#134283

I'm punting for now on the naming of RUST_TEST_NOCAPTURE. I feel like T-testing-devex should do a wider look at environment variables role in libtest before evaluating whether to

• Deprecate it in favor of the user passing CLI flags or the test runner providing its own config
• Deprecate in favor of RUST_TEST_NO_CAPTURE
• Deprecate in favor of RUST_TEST_CAPTURE

Other CLI flags were evaluated for casing consistency:

• --logfile has the same problem but was deprecated in rust-lang#134283

Fixes rust-lang#133073

bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Apr 27, 2025

ChrisDenton added a commit to ChrisDenton/rust that referenced this pull request

Apr 28, 2025

fix(test): Expose '--no-capture' in favor of --nocapture

This improves consistency with commonly expected CLI conventions, avoiding a common stutter people make when running tests (trying what they expect and then having to check the docs to then user whats accepted).

An alternative could have been to take a value, like --capture <value> (e.g. pytest does this). Overall, we're shifting focus for features to custom test harnesses (see rust-lang#134283). Most of pytests modes will likely be irrelevant in that situation. As for the rest, its too early to tell which, if any, may be relevant, so we're sticking with this small, quality of life improvement.

I expect we'll warn about --nocapture being deprecated in the future after a sufficient transition period has been allowed. By deprecating --nocapture, we intend that custom test harnesses do not need to support it for reasons outside of their own compatibility requirements, much like the deprecation in rust-lang#134283

I'm punting for now on the naming of RUST_TEST_NOCAPTURE. I feel like T-testing-devex should do a wider look at environment variables role in libtest before evaluating whether to

• Deprecate it in favor of the user passing CLI flags or the test runner providing its own config
• Deprecate in favor of RUST_TEST_NO_CAPTURE
• Deprecate in favor of RUST_TEST_CAPTURE

Other CLI flags were evaluated for casing consistency:

• --logfile has the same problem but was deprecated in rust-lang#134283

Regarding the implementation, I moved --nocapture out of optgroups(), into parse_opts(), out of an abundance of caution in passing the options without a deprecated value to the usage generation. However, the usage does not actually show optional flags, so this could potentially be dropped, simplifying the PR.

Note: compiletest added --no-capture instead of --nocapture in rust-lang#134809

T-testing-devex FCP: rust-lang#133073 (comment)

Fixes rust-lang#133073

bors added a commit to rust-lang-ci/rust that referenced this pull request

Apr 28, 2025

ChrisDenton added a commit to ChrisDenton/rust that referenced this pull request

Apr 28, 2025

fix(test): Expose '--no-capture' in favor of --nocapture

This improves consistency with commonly expected CLI conventions, avoiding a common stutter people make when running tests (trying what they expect and then having to check the docs to then user whats accepted).

An alternative could have been to take a value, like --capture <value> (e.g. pytest does this). Overall, we're shifting focus for features to custom test harnesses (see rust-lang#134283). Most of pytests modes will likely be irrelevant in that situation. As for the rest, its too early to tell which, if any, may be relevant, so we're sticking with this small, quality of life improvement.

I expect we'll warn about --nocapture being deprecated in the future after a sufficient transition period has been allowed. By deprecating --nocapture, we intend that custom test harnesses do not need to support it for reasons outside of their own compatibility requirements, much like the deprecation in rust-lang#134283

I'm punting for now on the naming of RUST_TEST_NOCAPTURE. I feel like T-testing-devex should do a wider look at environment variables role in libtest before evaluating whether to

• Deprecate it in favor of the user passing CLI flags or the test runner providing its own config
• Deprecate in favor of RUST_TEST_NO_CAPTURE
• Deprecate in favor of RUST_TEST_CAPTURE

Other CLI flags were evaluated for casing consistency:

• --logfile has the same problem but was deprecated in rust-lang#134283

Regarding the implementation, I moved --nocapture out of optgroups(), into parse_opts(), out of an abundance of caution in passing the options without a deprecated value to the usage generation. However, the usage does not actually show optional flags, so this could potentially be dropped, simplifying the PR.

Note: compiletest added --no-capture instead of --nocapture in rust-lang#134809

T-testing-devex FCP: rust-lang#133073 (comment)

Fixes rust-lang#133073

bors added a commit to rust-lang-ci/rust that referenced this pull request

Apr 28, 2025

bors added a commit to rust-lang-ci/rust that referenced this pull request

Apr 28, 2025

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Apr 28, 2025

Rollup merge of rust-lang#139224 - epage:nocapture, r=thomcc

fix(test): Expose '--no-capture' in favor of --nocapture

This improves consistency with commonly expected CLI conventions, avoiding a common stutter people make when running tests (trying what they expect and then having to check the docs to then user whats accepted).

An alternative could have been to take a value, like --capture <value> (e.g. pytest does this). Overall, we're shifting focus for features to custom test harnesses (see rust-lang#134283). Most of pytests modes will likely be irrelevant in that situation. As for the rest, its too early to tell which, if any, may be relevant, so we're sticking with this small, quality of life improvement.

I expect we'll warn about --nocapture being deprecated in the future after a sufficient transition period has been allowed. By deprecating --nocapture, we intend that custom test harnesses do not need to support it for reasons outside of their own compatibility requirements, much like the deprecation in rust-lang#134283

I'm punting for now on the naming of RUST_TEST_NOCAPTURE. I feel like T-testing-devex should do a wider look at environment variables role in libtest before evaluating whether to

• Deprecate it in favor of the user passing CLI flags or the test runner providing its own config
• Deprecate in favor of RUST_TEST_NO_CAPTURE
• Deprecate in favor of RUST_TEST_CAPTURE

Other CLI flags were evaluated for casing consistency:

• --logfile has the same problem but was deprecated in rust-lang#134283

Regarding the implementation, I moved --nocapture out of optgroups(), into parse_opts(), out of an abundance of caution in passing the options without a deprecated value to the usage generation. However, the usage does not actually show optional flags, so this could potentially be dropped, simplifying the PR.

Note: compiletest added --no-capture instead of --nocapture in rust-lang#134809

T-testing-devex FCP: rust-lang#133073 (comment)

Fixes rust-lang#133073

epage deleted the nocapture branch

April 28, 2025 11:39

github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request

May 9, 2025

fix(test): Expose '--no-capture' in favor of --nocapture

This improves consistency with commonly expected CLI conventions, avoiding a common stutter people make when running tests (trying what they expect and then having to check the docs to then user whats accepted).

An alternative could have been to take a value, like --capture <value> (e.g. pytest does this). Overall, we're shifting focus for features to custom test harnesses (see rust-lang#134283). Most of pytests modes will likely be irrelevant in that situation. As for the rest, its too early to tell which, if any, may be relevant, so we're sticking with this small, quality of life improvement.

I expect we'll warn about --nocapture being deprecated in the future after a sufficient transition period has been allowed. By deprecating --nocapture, we intend that custom test harnesses do not need to support it for reasons outside of their own compatibility requirements, much like the deprecation in rust-lang#134283

I'm punting for now on the naming of RUST_TEST_NOCAPTURE. I feel like T-testing-devex should do a wider look at environment variables role in libtest before evaluating whether to

• Deprecate it in favor of the user passing CLI flags or the test runner providing its own config
• Deprecate in favor of RUST_TEST_NO_CAPTURE
• Deprecate in favor of RUST_TEST_CAPTURE

Other CLI flags were evaluated for casing consistency:

• --logfile has the same problem but was deprecated in rust-lang#134283

Regarding the implementation, I moved --nocapture out of optgroups(), into parse_opts(), out of an abundance of caution in passing the options without a deprecated value to the usage generation. However, the usage does not actually show optional flags, so this could potentially be dropped, simplifying the PR.

Note: compiletest added --no-capture instead of --nocapture in rust-lang#134809

T-testing-devex FCP: rust-lang#133073 (comment)

Fixes rust-lang#133073

wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request

Jun 29, 2025

Pkgsrc changes:

• Adjust patches to adapt to upstream changes and new versions.
• associated checksums

Upstream changes relative to 1.87.0:

Version 1.88.0 (2025-06-26)

Language

• [Stabilize #![feature(let_chains)] in the 2024 edition.] (rust-lang/rust#132833) This feature allows &&-chaining let statements inside if and while, allowing intermixture with boolean expressions. The patterns inside the let sub-expressions can be irrefutable or refutable.
• [Stabilize #![feature(naked_functions)].] (rust-lang/rust#134213) Naked functions allow writing functions with no compiler-generated epilogue and prologue, allowing full control over the generated assembly for a particular function.
• [Stabilize #![feature(cfg_boolean_literals)].] (rust-lang/rust#138632) This allows using boolean literals as cfg predicates, e.g. #[cfg(true)] and #[cfg(false)].
• [Fully de-stabilize the #[bench] attribute] (rust-lang/rust#134273). Usage of #[bench] without #![feature(custom_test_frameworks)] already triggered a deny-by-default future-incompatibility lint since Rust 1.77, but will now become a hard error.
• [Add warn-by-default dangerous_implicit_autorefs lint against implicit autoref of raw pointer dereference.] (rust-lang/rust#123239) The lint [will be bumped to deny-by-default] (rust-lang/rust#141661) in the next version of Rust.
• [Add invalid_null_arguments lint to prevent invalid usage of null pointers.] (rust-lang/rust#119220) This lint is uplifted from clippy::invalid_null_ptr_usage.
• [Change trait impl candidate preference for builtin impls and trivial where-clauses.] (rust-lang/rust#138176)
• [Check types of generic const parameter defaults] (rust-lang/rust#139646)

Compiler

• [Stabilize -Cdwarf-version for selecting the version of DWARF debug information to generate.] (rust-lang/rust#136926)

Platform Support

• [Demote i686-pc-windows-gnu to Tier 2.] (https://blog.rust-lang.org/2025/05/26/demoting-i686-pc-windows-gnu/)

Refer to Rust's platform support page for more information on Rust's tiered platform support.

Libraries

• [Remove backticks from #[should_panic] test failure message.] (rust-lang/rust#136160)
• [Guarantee that [T; N]::from_fn is generated in order of increasing indices.] (rust-lang/rust#139099), for those passing it a stateful closure.
• [The libtest flag --nocapture is deprecated in favor of the more consistent --no-capture flag.] (rust-lang/rust#139224)
• [Guarantee that {float}::NAN is a quiet NaN.] (rust-lang/rust#139483)

Stabilized APIs

• [Cell::update] (https://doc.rust-lang.org/stable/std/cell/struct.Cell.html#method.update)
• [impl Default for *const T] (https://doc.rust-lang.org/nightly/std/primitive.pointer.html#impl-Default-for-*const+T)
• [impl Default for *mut T] (https://doc.rust-lang.org/nightly/std/primitive.pointer.html#impl-Default-for-*mut+T)
• [HashMap::extract_if] (https://doc.rust-lang.org/stable/std/collections/struct.HashMap.html#method.extract_if)
• [HashSet::extract_if] (https://doc.rust-lang.org/stable/std/collections/struct.HashSet.html#method.extract_if)
• [proc_macro::Span::line] (https://doc.rust-lang.org/stable/proc_macro/struct.Span.html#method.line)
• [proc_macro::Span::column] (https://doc.rust-lang.org/stable/proc_macro/struct.Span.html#method.column)
• [proc_macro::Span::start] (https://doc.rust-lang.org/stable/proc_macro/struct.Span.html#method.start)
• [proc_macro::Span::end] (https://doc.rust-lang.org/stable/proc_macro/struct.Span.html#method.end)
• [proc_macro::Span::file] (https://doc.rust-lang.org/stable/proc_macro/struct.Span.html#method.file)
• [proc_macro::Span::local_file] (https://doc.rust-lang.org/stable/proc_macro/struct.Span.html#method.local_file)

These previously stable APIs are now stable in const contexts:

• [NonNull<T>::replace] (https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.replace)
• [<*mut T>::replace] (https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.replace)
• [std::ptr::swap_nonoverlapping] (rust-lang/rust#137280)
• [Cell::{replace, get, get_mut, from_mut, as_slice_of_cells}] (rust-lang/rust#137928)

Cargo

• [Stabilize automatic garbage collection.] (rust-lang/cargo#14287)
• [use zlib-rs for gzip compression in rust code] (rust-lang/cargo#15417)

Rustdoc

• [Doctests can be ignored based on target names using ignore-* attributes.] (rust-lang/rust#137096)
• [Stabilize the --test-runtool and --test-runtool-arg CLI options to specify a program (like qemu) and its arguments to run a doctest.] (rust-lang/rust#137096)

Compatibility Notes

• [Finish changing the internal representation of pasted tokens] (rust-lang/rust#124141). Certain invalid declarative macros that were previously accepted in obscure circumstances are now correctly rejected by the compiler. Use of a tt fragment specifier can often fix these macros.
• [Fully de-stabilize the #[bench] attribute] (rust-lang/rust#134273). Usage of #[bench] without #![feature(custom_test_frameworks)] already triggered a deny-by-default future-incompatibility lint since Rust 1.77, but will now become a hard error.
• [Fix borrow checking some always-true patterns.] (rust-lang/rust#139042) The borrow checker was overly permissive in some cases, allowing programs that shouldn't have compiled.
• [Update the minimum external LLVM to 19.] (rust-lang/rust#139275)
• [Make it a hard error to use a vector type with a non-Rust ABI without enabling the required target feature.] (rust-lang/rust#139309)