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

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][platform-support-doc]
for more information on Rust's tiered platform support.

[platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html

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)

Like with rust-lang#139224, this is a documentation-only deprecation for now.
Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to
  compatibility)

Longer term, we expect test runners, like `cargo test`, to provide the
necessary mechanisms for environmental or persistent configuration (e.g.
using cargo config which supports `.cargo/config.toml` as well as
environment variables).

This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)

The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to
  implement
- Reduce the mechanisms that test runners, like `cargo test`, are
  expected to track when they are being bypassed to protect against
  negative interactions, e.g.  `RUST_TEST_NOCAPTURE=1` when json output
  is being read.

For testing-devex FCP, see rust-lang/testing-devex-team#10

Fixes rust-lang/testing-devex-team#10

History
-------

At each step, I could not find evidence of design discussions on whether
to support CLI, env, or both.  The first env variable seems to come from
the fact that it was being forked out of an existing env variable that
had a much wider scope.

At best, this seems like a way to offer a more persistent configuration
for these flags but environment variables hidden away in libtest is a
bit clunky and this seems like the wrong layer to handle this problem.

**Originally:** `RUST_THREADS` was respected by the Rust runtime and
libextra/test got this for free

**2013:** rust-lang#7335 suggested splitting `RUST_TEST_TASKS` out
of `RUST_THREADS`.  In that issue and the implementation
(rust-lang#8823).

**2014:** rust-lang#13374 ask for support to disable capturing of
stdout/stderr.  `--nocapture` and `RUST_TEST_NOCAPTURE` were added
together.

**2015:** rust-lang#23525 renamed `RUST_TEST_TASKS` to
`RUST_TEST_THREADS`

**2016:** rust-lang#25636 asked to configure `RUST_TEST_THREADS`
via `--test-threads` which was implemented in rust-lang#35414

**2021:** rust-lang#85440 asked for test randomization which was
implemented in rust-lang#89082, adding `--shuffle` /
RUST_TEST_SHUFFLE` and `--shuffle-seed SEED` / `RUST_TEST_SHUFFLE_SEED`

Potentially relevant issues
---------------------------

- rust-lang#74845

Deprecate RUST_TEST_* env variables

Like with rust-lang#139224, this is a documentation-only deprecation for now. Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to compatibility)

Longer term, we expect test runners, like `cargo test`, to provide the necessary mechanisms for environmental or persistent configuration (e.g. using cargo config which supports `.cargo/config.toml` as well as environment variables).

This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)

The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to implement
- Reduce the mechanisms that test runners, like `cargo test`, are expected to track when they are being bypassed to protect against negative interactions, e.g.  `RUST_TEST_NOCAPTURE=1` when json output is being read.

For testing-devex FCP, see rust-lang/testing-devex-team#10

Fixes rust-lang/testing-devex-team#10

History
-------

At each step, I could not find evidence of design discussions on whether to support CLI, env, or both.  The first env variable seems to come from the fact that it was being forked out of an existing env variable that had a much wider scope.

At best, this seems like a way to offer a more persistent configuration for these flags but environment variables hidden away in libtest is a bit clunky and this seems like the wrong layer to handle this problem.

**Originally:** `RUST_THREADS` was respected by the Rust runtime and libextra/test got this for free

**2013:** rust-lang#7335 suggested splitting `RUST_TEST_TASKS` out of `RUST_THREADS`.  In that issue and the implementation (rust-lang#8823).

**2014:** rust-lang#13374 ask for support to disable capturing of stdout/stderr.  `--nocapture` and `RUST_TEST_NOCAPTURE` were added together.

**2015:** rust-lang#23525 renamed `RUST_TEST_TASKS` to `RUST_TEST_THREADS`

**2016:** rust-lang#25636 asked to configure `RUST_TEST_THREADS` via `--test-threads` which was implemented in rust-lang#35414

**2021:** rust-lang#85440 asked for test randomization which was implemented in rust-lang#89082, adding `--shuffle` / RUST_TEST_SHUFFLE` and `--shuffle-seed SEED` / `RUST_TEST_SHUFFLE_SEED`

Potentially relevant issues
---------------------------

- rust-lang#74845

Deprecate RUST_TEST_* env variables

Like with rust-lang#139224, this is a documentation-only deprecation for now. Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to compatibility)

Longer term, we expect test runners, like `cargo test`, to provide the necessary mechanisms for environmental or persistent configuration (e.g. using cargo config which supports `.cargo/config.toml` as well as environment variables).

This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)

The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to implement
- Reduce the mechanisms that test runners, like `cargo test`, are expected to track when they are being bypassed to protect against negative interactions, e.g.  `RUST_TEST_NOCAPTURE=1` when json output is being read.

For testing-devex FCP, see rust-lang/testing-devex-team#10

Fixes rust-lang/testing-devex-team#10

History
-------

At each step, I could not find evidence of design discussions on whether to support CLI, env, or both.  The first env variable seems to come from the fact that it was being forked out of an existing env variable that had a much wider scope.

At best, this seems like a way to offer a more persistent configuration for these flags but environment variables hidden away in libtest is a bit clunky and this seems like the wrong layer to handle this problem.

**Originally:** `RUST_THREADS` was respected by the Rust runtime and libextra/test got this for free

**2013:** rust-lang#7335 suggested splitting `RUST_TEST_TASKS` out of `RUST_THREADS`.  In that issue and the implementation (rust-lang#8823).

**2014:** rust-lang#13374 ask for support to disable capturing of stdout/stderr.  `--nocapture` and `RUST_TEST_NOCAPTURE` were added together.

**2015:** rust-lang#23525 renamed `RUST_TEST_TASKS` to `RUST_TEST_THREADS`

**2016:** rust-lang#25636 asked to configure `RUST_TEST_THREADS` via `--test-threads` which was implemented in rust-lang#35414

**2021:** rust-lang#85440 asked for test randomization which was implemented in rust-lang#89082, adding `--shuffle` / RUST_TEST_SHUFFLE` and `--shuffle-seed SEED` / `RUST_TEST_SHUFFLE_SEED`

Potentially relevant issues
---------------------------

- rust-lang#74845

Deprecate RUST_TEST_* env variables

Like with rust-lang#139224, this is a documentation-only deprecation for now. Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to compatibility)

Longer term, we expect test runners, like `cargo test`, to provide the necessary mechanisms for environmental or persistent configuration (e.g. using cargo config which supports `.cargo/config.toml` as well as environment variables).

This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)

The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to implement
- Reduce the mechanisms that test runners, like `cargo test`, are expected to track when they are being bypassed to protect against negative interactions, e.g.  `RUST_TEST_NOCAPTURE=1` when json output is being read.

For testing-devex FCP, see rust-lang/testing-devex-team#10

Fixes rust-lang/testing-devex-team#10

History
-------

At each step, I could not find evidence of design discussions on whether to support CLI, env, or both.  The first env variable seems to come from the fact that it was being forked out of an existing env variable that had a much wider scope.

At best, this seems like a way to offer a more persistent configuration for these flags but environment variables hidden away in libtest is a bit clunky and this seems like the wrong layer to handle this problem.

**Originally:** `RUST_THREADS` was respected by the Rust runtime and libextra/test got this for free

**2013:** rust-lang#7335 suggested splitting `RUST_TEST_TASKS` out of `RUST_THREADS`.  In that issue and the implementation (rust-lang#8823).

**2014:** rust-lang#13374 ask for support to disable capturing of stdout/stderr.  `--nocapture` and `RUST_TEST_NOCAPTURE` were added together.

**2015:** rust-lang#23525 renamed `RUST_TEST_TASKS` to `RUST_TEST_THREADS`

**2016:** rust-lang#25636 asked to configure `RUST_TEST_THREADS` via `--test-threads` which was implemented in rust-lang#35414

**2021:** rust-lang#85440 asked for test randomization which was implemented in rust-lang#89082, adding `--shuffle` / RUST_TEST_SHUFFLE` and `--shuffle-seed SEED` / `RUST_TEST_SHUFFLE_SEED`

Potentially relevant issues
---------------------------

- rust-lang#74845

Deprecate RUST_TEST_* env variables

Like with rust-lang#139224, this is a documentation-only deprecation for now. Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to compatibility)

Longer term, we expect test runners, like `cargo test`, to provide the necessary mechanisms for environmental or persistent configuration (e.g. using cargo config which supports `.cargo/config.toml` as well as environment variables).

This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)

The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to implement
- Reduce the mechanisms that test runners, like `cargo test`, are expected to track when they are being bypassed to protect against negative interactions, e.g.  `RUST_TEST_NOCAPTURE=1` when json output is being read.

For testing-devex FCP, see rust-lang/testing-devex-team#10

Fixes rust-lang/testing-devex-team#10

History
-------

At each step, I could not find evidence of design discussions on whether to support CLI, env, or both.  The first env variable seems to come from the fact that it was being forked out of an existing env variable that had a much wider scope.

At best, this seems like a way to offer a more persistent configuration for these flags but environment variables hidden away in libtest is a bit clunky and this seems like the wrong layer to handle this problem.

**Originally:** `RUST_THREADS` was respected by the Rust runtime and libextra/test got this for free

**2013:** rust-lang#7335 suggested splitting `RUST_TEST_TASKS` out of `RUST_THREADS`.  In that issue and the implementation (rust-lang#8823).

**2014:** rust-lang#13374 ask for support to disable capturing of stdout/stderr.  `--nocapture` and `RUST_TEST_NOCAPTURE` were added together.

**2015:** rust-lang#23525 renamed `RUST_TEST_TASKS` to `RUST_TEST_THREADS`

**2016:** rust-lang#25636 asked to configure `RUST_TEST_THREADS` via `--test-threads` which was implemented in rust-lang#35414

**2021:** rust-lang#85440 asked for test randomization which was implemented in rust-lang#89082, adding `--shuffle` / RUST_TEST_SHUFFLE` and `--shuffle-seed SEED` / `RUST_TEST_SHUFFLE_SEED`

Potentially relevant issues
---------------------------

- rust-lang#74845

Deprecate RUST_TEST_* env variables

Like with rust-lang#139224, this is a documentation-only deprecation for now. Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to compatibility)

Longer term, we expect test runners, like `cargo test`, to provide the necessary mechanisms for environmental or persistent configuration (e.g. using cargo config which supports `.cargo/config.toml` as well as environment variables).

This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)

The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to implement
- Reduce the mechanisms that test runners, like `cargo test`, are expected to track when they are being bypassed to protect against negative interactions, e.g.  `RUST_TEST_NOCAPTURE=1` when json output is being read.

For testing-devex FCP, see rust-lang/testing-devex-team#10

Fixes rust-lang/testing-devex-team#10

History
-------

At each step, I could not find evidence of design discussions on whether to support CLI, env, or both.  The first env variable seems to come from the fact that it was being forked out of an existing env variable that had a much wider scope.

At best, this seems like a way to offer a more persistent configuration for these flags but environment variables hidden away in libtest is a bit clunky and this seems like the wrong layer to handle this problem.

**Originally:** `RUST_THREADS` was respected by the Rust runtime and libextra/test got this for free

**2013:** rust-lang#7335 suggested splitting `RUST_TEST_TASKS` out of `RUST_THREADS`.  In that issue and the implementation (rust-lang#8823).

**2014:** rust-lang#13374 ask for support to disable capturing of stdout/stderr.  `--nocapture` and `RUST_TEST_NOCAPTURE` were added together.

**2015:** rust-lang#23525 renamed `RUST_TEST_TASKS` to `RUST_TEST_THREADS`

**2016:** rust-lang#25636 asked to configure `RUST_TEST_THREADS` via `--test-threads` which was implemented in rust-lang#35414

**2021:** rust-lang#85440 asked for test randomization which was implemented in rust-lang#89082, adding `--shuffle` / RUST_TEST_SHUFFLE` and `--shuffle-seed SEED` / `RUST_TEST_SHUFFLE_SEED`

Potentially relevant issues
---------------------------

- rust-lang#74845

Rollup merge of #145269 - epage:test-env, r=jhpratt

Deprecate RUST_TEST_* env variables

Like with #139224, this is a documentation-only deprecation for now. Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to compatibility)

Longer term, we expect test runners, like `cargo test`, to provide the necessary mechanisms for environmental or persistent configuration (e.g. using cargo config which supports `.cargo/config.toml` as well as environment variables).

This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)

The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to implement
- Reduce the mechanisms that test runners, like `cargo test`, are expected to track when they are being bypassed to protect against negative interactions, e.g.  `RUST_TEST_NOCAPTURE=1` when json output is being read.

For testing-devex FCP, see rust-lang/testing-devex-team#10

Fixes rust-lang/testing-devex-team#10

History
-------

At each step, I could not find evidence of design discussions on whether to support CLI, env, or both.  The first env variable seems to come from the fact that it was being forked out of an existing env variable that had a much wider scope.

At best, this seems like a way to offer a more persistent configuration for these flags but environment variables hidden away in libtest is a bit clunky and this seems like the wrong layer to handle this problem.

**Originally:** `RUST_THREADS` was respected by the Rust runtime and libextra/test got this for free

**2013:** #7335 suggested splitting `RUST_TEST_TASKS` out of `RUST_THREADS`.  In that issue and the implementation (#8823).

**2014:** #13374 ask for support to disable capturing of stdout/stderr.  `--nocapture` and `RUST_TEST_NOCAPTURE` were added together.

**2015:** #23525 renamed `RUST_TEST_TASKS` to `RUST_TEST_THREADS`

**2016:** #25636 asked to configure `RUST_TEST_THREADS` via `--test-threads` which was implemented in #35414

**2021:** #85440 asked for test randomization which was implemented in #89082, adding `--shuffle` / RUST_TEST_SHUFFLE` and `--shuffle-seed SEED` / `RUST_TEST_SHUFFLE_SEED`

Potentially relevant issues
---------------------------

- #74845

Deprecate RUST_TEST_* env variables

Like with rust-lang#139224, this is a documentation-only deprecation for now. Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to compatibility)

Longer term, we expect test runners, like `cargo test`, to provide the necessary mechanisms for environmental or persistent configuration (e.g. using cargo config which supports `.cargo/config.toml` as well as environment variables).

This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)

The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to implement
- Reduce the mechanisms that test runners, like `cargo test`, are expected to track when they are being bypassed to protect against negative interactions, e.g.  `RUST_TEST_NOCAPTURE=1` when json output is being read.

For testing-devex FCP, see rust-lang/testing-devex-team#10

Fixes rust-lang/testing-devex-team#10

History
-------

At each step, I could not find evidence of design discussions on whether to support CLI, env, or both.  The first env variable seems to come from the fact that it was being forked out of an existing env variable that had a much wider scope.

At best, this seems like a way to offer a more persistent configuration for these flags but environment variables hidden away in libtest is a bit clunky and this seems like the wrong layer to handle this problem.

**Originally:** `RUST_THREADS` was respected by the Rust runtime and libextra/test got this for free

**2013:** rust-lang#7335 suggested splitting `RUST_TEST_TASKS` out of `RUST_THREADS`.  In that issue and the implementation (rust-lang#8823).

**2014:** rust-lang#13374 ask for support to disable capturing of stdout/stderr.  `--nocapture` and `RUST_TEST_NOCAPTURE` were added together.

**2015:** rust-lang#23525 renamed `RUST_TEST_TASKS` to `RUST_TEST_THREADS`

**2016:** rust-lang#25636 asked to configure `RUST_TEST_THREADS` via `--test-threads` which was implemented in rust-lang#35414

**2021:** rust-lang#85440 asked for test randomization which was implemented in rust-lang#89082, adding `--shuffle` / RUST_TEST_SHUFFLE` and `--shuffle-seed SEED` / `RUST_TEST_SHUFFLE_SEED`

Potentially relevant issues
---------------------------

- rust-lang#74845

…ddle

rustdoc: Rename unstable option `--nocapture` to `--no-capture` in accordance with `libtest`

Context: rust-lang#133073, rust-lang#139224 (TL;DR: `libtest` has soft-deprecated `--nocapture` in favor a new & stable `--no-capture`; we should follow suit).

Since the rustdoc flag is unstable (tracking issue: rust-lang#148116), we're allowed to remove the old flag immediately. However since the flag has existed for 4 years we could hard-deprecate the flag first or at least be considerate and provide a diagnostic referring users to the new flag. This PR does neither. Let me know what you would think would be best.

Cargo doesn't use this flag, not yet at least (rust-lang/cargo#9705), so we really are free to sunset this flag without bigger consequences.

…ddle

rustdoc: Rename unstable option `--nocapture` to `--no-capture` in accordance with `libtest`

Context: rust-lang#133073, rust-lang#139224 (TL;DR: `libtest` has soft-deprecated `--nocapture` in favor a new & stable `--no-capture`; we should follow suit).

Since the rustdoc flag is unstable (tracking issue: rust-lang#148116), we're allowed to remove the old flag immediately. However since the flag has existed for 4 years we could hard-deprecate the flag first or at least be considerate and provide a diagnostic referring users to the new flag. This PR does neither. Let me know what you would think would be best.

Cargo doesn't use this flag, not yet at least (rust-lang/cargo#9705), so we really are free to sunset this flag without bigger consequences.

…ddle

rustdoc: Rename unstable option `--nocapture` to `--no-capture` in accordance with `libtest`

Context: rust-lang#133073, rust-lang#139224 (TL;DR: `libtest` has soft-deprecated `--nocapture` in favor a new & stable `--no-capture`; we should follow suit).

Since the rustdoc flag is unstable (tracking issue: rust-lang#148116), we're allowed to remove the old flag immediately. However since the flag has existed for 4 years we could hard-deprecate the flag first or at least be considerate and provide a diagnostic referring users to the new flag. This PR does neither. Let me know what you would think would be best.

Cargo doesn't use this flag, not yet at least (rust-lang/cargo#9705), so we really are free to sunset this flag without bigger consequences.

Rollup merge of #148115 - fmease:rustdoc-no-capture, r=notriddle

rustdoc: Rename unstable option `--nocapture` to `--no-capture` in accordance with `libtest`

Context: #133073, #139224 (TL;DR: `libtest` has soft-deprecated `--nocapture` in favor a new & stable `--no-capture`; we should follow suit).

Since the rustdoc flag is unstable (tracking issue: #148116), we're allowed to remove the old flag immediately. However since the flag has existed for 4 years we could hard-deprecate the flag first or at least be considerate and provide a diagnostic referring users to the new flag. This PR does neither. Let me know what you would think would be best.

Cargo doesn't use this flag, not yet at least (rust-lang/cargo#9705), so we really are free to sunset this flag without bigger consequences.

rustdoc: Rename unstable option `--nocapture` to `--no-capture` in accordance with `libtest`

Context: rust-lang/rust#133073, rust-lang/rust#139224 (TL;DR: `libtest` has soft-deprecated `--nocapture` in favor a new & stable `--no-capture`; we should follow suit).

Since the rustdoc flag is unstable (tracking issue: rust-lang/rust#148116), we're allowed to remove the old flag immediately. However since the flag has existed for 4 years we could hard-deprecate the flag first or at least be considerate and provide a diagnostic referring users to the new flag. This PR does neither. Let me know what you would think would be best.

Cargo doesn't use this flag, not yet at least (rust-lang/cargo#9705), so we really are free to sunset this flag without bigger consequences.

…ddle

rustdoc: Rename unstable option `--nocapture` to `--no-capture` in accordance with `libtest`

Context: rust-lang#133073, rust-lang#139224 (TL;DR: `libtest` has soft-deprecated `--nocapture` in favor a new & stable `--no-capture`; we should follow suit).

Since the rustdoc flag is unstable (tracking issue: rust-lang#148116), we're allowed to remove the old flag immediately. However since the flag has existed for 4 years we could hard-deprecate the flag first or at least be considerate and provide a diagnostic referring users to the new flag. This PR does neither. Let me know what you would think would be best.

Cargo doesn't use this flag, not yet at least (rust-lang/cargo#9705), so we really are free to sunset this flag without bigger consequences.

…ddle

rustdoc: Rename unstable option `--nocapture` to `--no-capture` in accordance with `libtest`

Context: rust-lang#133073, rust-lang#139224 (TL;DR: `libtest` has soft-deprecated `--nocapture` in favor a new & stable `--no-capture`; we should follow suit).

Since the rustdoc flag is unstable (tracking issue: rust-lang#148116), we're allowed to remove the old flag immediately. However since the flag has existed for 4 years we could hard-deprecate the flag first or at least be considerate and provide a diagnostic referring users to the new flag. This PR does neither. Let me know what you would think would be best.

Cargo doesn't use this flag, not yet at least (rust-lang/cargo#9705), so we really are free to sunset this flag without bigger consequences.

rustdoc: Rename unstable option `--nocapture` to `--no-capture` in accordance with `libtest`

Context: rust-lang/rust#133073, rust-lang/rust#139224 (TL;DR: `libtest` has soft-deprecated `--nocapture` in favor a new & stable `--no-capture`; we should follow suit).

Since the rustdoc flag is unstable (tracking issue: rust-lang/rust#148116), we're allowed to remove the old flag immediately. However since the flag has existed for 4 years we could hard-deprecate the flag first or at least be considerate and provide a diagnostic referring users to the new flag. This PR does neither. Let me know what you would think would be best.

Cargo doesn't use this flag, not yet at least (rust-lang/cargo#9705), so we really are free to sunset this flag without bigger consequences.