Add --no-capture/--nocapture as bootstrap arguments by clubby789 · Pull Request #134809 · rust-lang/rust (original) (raw)

clubby789

I often try x test ... --nocapture => 'unknown argument' => x test ... -- --nocapture. As we forward several other compiletest flags, let's recognise this one in bootstrap as well.

@rustbot

r? @albertlarsan68

rustbot has assigned @albertlarsan68.
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-bootstrap

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

labels

Dec 26, 2024

@rustbot

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

jieyouxu

Member

@jieyouxu jieyouxu left a comment • Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I contend that we should only support the sane --no-capture flag that follows common CLI conventions, and not support the current libtest --nocapture naming. The changes themselves look reasonable otherwise.

@jieyouxu jieyouxu added S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

and removed S-waiting-on-review

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

labels

Dec 27, 2024

@clubby789

The thought was that while we're transitioning it would be nice to support both. But I suppose we shouldn't be introducing new uses of the 'bad' version. Will remove

@clubby789

@clubby789

@rustbot

Some changes occurred in src/tools/compiletest

cc @jieyouxu

jieyouxu

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things:

  1. Can you also add a change tracker entry, since this is adding a new bootstrap cli flag?
  2. Could you also slightly update rustc-dev-guide so people can find out that this is a thing now?

Otherwise, this is a very nice testing UX improvement. Thanks!

@clubby789

jieyouxu

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this LGTM. Please r=me after PR CI is green.

@clubby789

@bors

📌 Commit 35bbb01 has been approved by jieyouxu

It is now in the queue for this repository.

@bors 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-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Dec 27, 2024

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

Dec 27, 2024

@bors

…iaskrgr

Rollup of 6 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

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

Dec 27, 2024

@rust-timer

Rollup merge of rust-lang#134809 - clubby789:nocapture, r=jieyouxu

Add --no-capture/--nocapture as bootstrap arguments

I often try x test ... --nocapture => 'unknown argument' => x test ... -- --nocapture. As we forward several other compiletest flags, let's recognise this one in bootstrap as well.

poliorcetics pushed a commit to poliorcetics/rust that referenced this pull request

Dec 28, 2024

@matthiaskrgr @poliorcetics

Add --no-capture/--nocapture as bootstrap arguments

I often try x test ... --nocapture => 'unknown argument' => x test ... -- --nocapture. As we forward several other compiletest flags, let's recognise this one in bootstrap as well.

poliorcetics pushed a commit to poliorcetics/rust that referenced this pull request

Dec 28, 2024

@bors @poliorcetics

…iaskrgr

Rollup of 6 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

@epage epage mentioned this pull request

Apr 14, 2025

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

Apr 28, 2025

@ChrisDenton

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

Other CLI flags were evaluated for casing consistency:

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

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

Apr 28, 2025

@ChrisDenton

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

Other CLI flags were evaluated for casing consistency:

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

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

Apr 28, 2025

@ChrisDenton

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

Other CLI flags were evaluated for casing consistency:

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

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

Apr 28, 2025

@rust-timer

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

Other CLI flags were evaluated for casing consistency:

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