| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
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 #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.
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 #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 #134283
Fixes #133073
|
|
This will help with hiding some options in `--help`
|
|
rust-lang/testing-devex-team#9 proposed changing the behavior of `--logfile`.
The given reasons were:
(1) Bazel can't programmatically process stdout. This seems like a
limitation in Bazel and we recommend focusing on that. If we look at
the wider Rust ecosystem, Rustc and Cargo don't support any such
mechanism and the Cargo team rejected having one. Expecting this in
libtest when its not supported elsewhere seems too specialized.
(2) Tests that leak out non-programmatic output that intermixes with
programmatic output. We acknowledge this is a problem to be evaluated
but we need to make sure we are stepping back and gathering
requirements, rather than assuming `--logfile` will fit the needs.
Independent of the motive, regarding using or changing `--logfile`
(1) Most ways to do it would be a breaking change, like if we respect
any stable `--format`. As suggested above, we could specialize this to
new `--format` values but that would be confusing for some values to
apply but not others.
(2) Other ways of solving this add new features to lib`test` when we are
instead wanting to limit the feature set it has to minimize the
compatibility surface that has to be maintained and the burden it would
put on third party harnesses which are a focus area. Examples include
`--format compact` or a `--log-format` flag
(3) The existence of `--logfile` dates back quite a ways
(https://github.com/rust-lang/rust/commit/5cc050b265509c19717e11e12dd785d8c73f5b11,
rust-lang/rust#2127) and the history gives the
impression this more of slipped through rather than being an intended
feature (see also
https://github.com/rust-lang/rust/pull/82350#discussion_r579732071).
Deprecation would better match to how it has been treated.
By deprecating this, we do not expect custom test harnesses
(rust-lang/testing-devex-team#2) to implement this.
T-testing-devex held an FCP for deprecating in rust-lang/testing-devex-team#9
though according to
[RFC #3455](https://rust-lang.github.io/rfcs/3455-t-test.html),
this is still subject to final approval from T-libs-api.
|
|
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
|
|
"only accepted on the nightly compiler" is misleading when this *is* nightly.
|
|
Two locations check whether this build-time environment variable is
defined. Allowing it to be explicitly disabled with a "0" value is
useful, especially for integrating with external build systems.
|
|
|
|
|
|
The UNIX and WASI implementations use `isatty`. The Windows
implementation uses the same logic the `atty` crate uses, including the
hack needed to detect msys terminals.
Implement this trait for `File` and for `Stdin`/`Stdout`/`Stderr` and
their locked counterparts on all platforms. On UNIX and WASI, implement
it for `BorrowedFd`/`OwnedFd`. On Windows, implement it for
`BorrowedHandle`/`OwnedHandle`.
Based on https://github.com/rust-lang/rust/pull/91121
Co-authored-by: Matt Wilkinson <mattwilki17@gmail.com>
|
|
|
|
This updates the standard library's documentation to use the new syntax. The
documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.
A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).
|
|
Essentially, what is described here:
https://github.com/rust-lang/rust/issues/64888#issuecomment-1008047228
There is one difference. The comment proposes to add a
`--report-time-color` option. This change instead uses libtest's
existing `--color` option for that purpose.
|
|
|
|
|
|
|
|
|
|
libtest: allow multiple filters
Libtest ignores any filters after the first. This changes it so that if multiple filters are passed, it will test against all of them.
This also affects compiletest to do the same.
Closes #30422
|
|
|
|
|
|
|
