…iaskrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#133663 (Add a compiler intrinsic to back `bigint_helper_methods`)
 - rust-lang#134798 (Make `ty::Error` implement all auto traits)
 - rust-lang#134808 (compiletest: Remove empty 'expected' files when blessing)
 - rust-lang#134809 (Add `--no-capture`/`--nocapture` as bootstrap arguments)
 - rust-lang#134826 (Add spastorino to users_on_vacation)
 - rust-lang#134828 (Add clubby789 back to bootstrap review rotation)

r? `@ghost`
`@rustbot` modify labels: rollup

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.

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.

…iaskrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#133663 (Add a compiler intrinsic to back `bigint_helper_methods`)
 - rust-lang#134798 (Make `ty::Error` implement all auto traits)
 - rust-lang#134808 (compiletest: Remove empty 'expected' files when blessing)
 - rust-lang#134809 (Add `--no-capture`/`--nocapture` as bootstrap arguments)
 - rust-lang#134826 (Add spastorino to users_on_vacation)
 - rust-lang#134828 (Add clubby789 back to bootstrap review rotation)

r? `@ghost`
`@rustbot` modify labels: rollup

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 `pytest`s 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 lib`test` 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

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 `pytest`s 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 lib`test` 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

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 `pytest`s 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 lib`test` 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

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 `pytest`s 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 lib`test` 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

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 `pytest`s 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 lib`test` 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