| Age | Commit message (Collapse) | Author | Lines |
|---|
|
It is possible for different tests to collide to the same TestDesc
when macros are involved. That is a bug, but it didn’t cause a panic
until #81367. For now, change the code to ignore this problem.
Fixes #81852.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
(cherry picked from commit 1605af015c493c4800be9b56d7eb8d759f9a7d3c)
|
|
|
|
stabilise `cargo test -- --include-ignored`
stabilise `cargo test -- --include-ignored`
On stable there's no way to run ignored tests as well as the normal tests.
An example use case where stabilising this would help:
Exercism has some initial tests and then some additional ignored tests that people run currently with --ignore but currently they can't run all the tests in one go without being on nightly. It would be a little more ergonomic if this flag was stablilised.
( Fixes #65770 )
I built with ./x.py build -i library/test - but as libtest is a dylib is there an easy way to invoke it manually to check it's working as expected? (I've updated the automated tests.)
|
|
Print failure message on all tests that should panic, but don't
Fixes #80861. Tests with the `#[should_panic]` attribute should always print a failure message if no panic occurs, regardless of whether or not an `expected` panic message is specified.
|
|
This reduces the total complexity of checking timeouts from quadratic
to linear, and should also fix an unwrap of None on completion of an
already timed-out test.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
|
|
Otherwise we can miss bugs where a test reports that it succeeded but
then panics within a TLS destructor.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
|
|
This already happens with should_panic tests without an expected
message. This commit fixes should_panic tests with an expected message
to have the same behavior.
|
|
|
|
|
|
libtest: Print the total time taken to execute a test suite
Print the total time taken to execute a test suite by default, without any kind of flag.
Closes #75660
# Example
```
anon@anon:~/code/rust/example$ cargo test
Compiling example v0.1.0 (/home/anon/code/rust/example)
Finished test [unoptimized + debuginfo] target(s) in 0.18s
Running target/debug/deps/example-745b64d3885c3565
running 3 tests
test tests::foo ... ok
test tests::bar ... ok
test tests::baz ... ok
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s
Doc-tests example
running 3 tests
test src/lib.rs - foo (line 3) ... ok
test src/lib.rs - bar (line 11) ... ok
test src/lib.rs - baz (line 19) ... ok
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s
```
```
anon@anon:~/code/rust/example$ cargo test -- --format terse
Finished test [unoptimized + debuginfo] target(s) in 0.08s
Running target/debug/deps/example-745b64d3885c3565
running 3 tests
...
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s
Doc-tests example
running 3 tests
...
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s
```
```
anon@anon:~/code/rust/example$ cargo test -- --format json -Z unstable-options
Compiling example v0.1.0 (/home/anon/code/rust/example)
Finished test [unoptimized + debuginfo] target(s) in 0.25s
Running target/debug/deps/example-745b64d3885c3565
{ "type": "suite", "event": "started", "test_count": 3 }
{ "type": "test", "event": "started", "name": "tests::bar" }
{ "type": "test", "event": "started", "name": "tests::baz" }
{ "type": "test", "event": "started", "name": "tests::foo" }
{ "type": "test", "name": "tests::foo", "event": "ok" }
{ "type": "test", "name": "tests::bar", "event": "ok" }
{ "type": "test", "name": "tests::baz", "event": "ok" }
{ "type": "suite", "event": "ok", "passed": 3, "failed": 0, "allowed_fail": 0, "ignored": 0, "measured": 0, "filtered_out": 0, "exec_time": "1.2s" }
Doc-tests example
{ "type": "suite", "event": "started", "test_count": 3 }
{ "type": "test", "event": "started", "name": "src/lib.rs - bar (line 11)" }
{ "type": "test", "event": "started", "name": "src/lib.rs - baz (line 19)" }
{ "type": "test", "event": "started", "name": "src/lib.rs - foo (line 3)" }
{ "type": "test", "name": "src/lib.rs - foo (line 3)", "event": "ok" }
{ "type": "test", "name": "src/lib.rs - bar (line 11)", "event": "ok" }
{ "type": "test", "name": "src/lib.rs - baz (line 19)", "event": "ok" }
{ "type": "suite", "event": "ok", "passed": 3, "failed": 0, "allowed_fail": 0, "ignored": 0, "measured": 0, "filtered_out": 0, "exec_time": "1.3s" }
```
|
|
|
|
|
|
Drop support for all cloudabi targets
`cloudabi` is a tier-3 target, and [it is no longer being maintained upstream][no].
This PR drops supports for cloudabi targets. Those targets are:
* aarch64-unknown-cloudabi
* armv7-unknown-cloudabi
* i686-unknown-cloudabi
* x86_64-unknown-cloudabi
Since this drops supports for a target, I'd like somebody to tag `relnotes` label to this PR.
Some other issues:
* The tidy exception for `cloudabi` crate is still remained because
* `parking_lot v0.9.0` and `parking_lot v0.10.2` depends on `cloudabi v0.0.3`.
* `parking_lot v0.11.0` depends on `cloudabi v0.1.0`.
[no]: https://github.com/NuxiNL/cloudabi#note-this-project-is-unmaintained
|
|
|
|
|
|
There were no use cases for setting them separately.
Merging them simplifies some things.
|
|
|
|
make concurrency helper more pleasant to read
|
|
Capture output from threads spawned in tests
This is revival of #75172.
Original text:
> Fixes #42474.
>
> r? `@dtolnay` since you expressed interest in this, but feel free to redirect if you aren't the right person anymore.
---
Closes #75172.
|
|
Fixing escaping to ensure generation of welformed json.
doc tests' json name have a filename in them. When json test output is asked for on windows currently produces invalid json.
Tracking issue for json test output: #49359
|
|
Fixes #42474.
|
|
|
|
Add std::thread::available_concurrency
This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust, tracking issue https://github.com/rust-lang/rust/issues/74479.
cc/ `@rust-lang/libs`
## Motivation
Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform.
__edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups, but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186.
## Naming
Discussing the naming of the API on Zulip surfaced two options:
- `std::thread::hardware_concurrency`
- `std::thread::hardware_threads`
Both options seemed acceptable, but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the "hardware threads" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20):
> A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__, or harts, through multithreading.
It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency`, so we can't use that to help inform our decision here.
## Return type
An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option<NonZeroUsize>` as its return type, where `None` is returned on platforms where we don't know the number of hardware threads available.
The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known, they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use, but improving the ergonomics of them is something that I think we can address separately.
## Implementation
`@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.
|
|
|
|
Modern compilers allow reaching external crates
like std or core via relative paths in modules
outside of lib.rs and main.rs.
|
|
|
|
Found while working on https://github.com/rust-lang/rust/pull/77351;
these are just the ones that could be fixed automatically.
|
|
Dogfood total_cmp in the test crate
|
|
|
|
Replace write_fmt with write!
Latter is simpler
|
|
Latter is simpler
|
|
|
|
|
|
fix a couple of clippy findings
|
|
|
|
away
|
|
|
