Auto merge of #2398 - sunshowers:nextest-compat, r=RalfJung
[cargo-miri] support nextest
Add the ability to run `cargo miri nextest list` and `cargo miri nextest run`.
[cargo-nextest](https://nexte.st) is a new test runner for Rust maintained mostly by myself. It has several new features, but the most relevant to miri is the fact that it runs [each test in its own process](https://nexte.st/book/how-it-works.html#the-nextest-model). This gives miri users better leak detection (https://github.com/rust-lang/miri/issues/1481) for free, for example.
See https://github.com/nextest-rs/nextest/issues/181 for discussion, including comments by `@eddyb` and `@RalfJung.`
Future work might be to have miri read [the list of tests](https://docs.rs/nextest-metadata/latest/nextest_metadata/struct.TestListSummary.html) (or [test binaries](https://docs.rs/nextest-metadata/latest/nextest_metadata/struct.BinaryListSummary.html)) generated by `nextest list`. `@eddyb` thinks that might be useful.
I tested `cargo miri nextest run` against smallvec, and it worked great.
Note: Running tests out of archives is currently broken, as the comment in run-test.py explains.
Also handle get_alloc_extra the same throughout Stacked Borrows. I don't think this `unwrap` can actually cause an ICE since another part of SB will raise an error before, but still, seems strange to do this inconsistently in retagging vs expose_ptr.
Auto merge of #2373 - rust-lang:test_dependencies, r=RalfJung
Allow ui tests to have dependencies in a reliable way
This completely sidesteps the issue that compiletest-rs has where old artifacts of a dependency cause `multiple available crates of name XXX` errors. At this point I think we've reached feature parity for clippy, too, so I'm going to try publishing a version once this is merged.
Currently we skip this if a stderr diff was printed, but the stderr diff is normalized, so e.g. one cannot learn line numbers from it.
Is there a way to get the diff to only print the parts the differ, like a usual `diff -u`? Currently it always seems to print the full output, so with a long stderr we now get doubly long test results even if the diff is actually rather small.
Ben Kimock [Tue, 19 Jul 2022 21:08:17 +0000 (17:08 -0400)]
Fix bugs where unique_range became invalid
And also expand the cache integrity checks to cover this case, and
generally assert a lot more about the unique_range, then tighten up
sloppy implementation scenarios that this uncovered.
- detect when Miri got locally installed and is being run with the wrong toolchain
- when an ICE occurs, print a backtrace of where the interpreter was at the time
Auto merge of #2350 - RalfJung:remove-deprecated, r=oli-obk
remove deprecated options
These have been deprecated a month ago and nobody said they need them. Is that enough time? We can also let this PR sit a little.
Cc https://github.com/rust-lang/miri/issues/2187 https://github.com/rust-lang/miri/issues/2188
(keeping them open to track removing their supporting infrastructure in the core interpreter)
`@saethlin` I realized we need to gate this behind the isolation flag, sorry. :/ The point of isolated mode is that it is 100% deterministic, so we cannot call host functions that might give different answers on different runs.
Per https://github.com/rust-lang/miri/issues/2292#issuecomment-1171858283, this is an attempt at
> do something more clever with Miri's `isatty` shim
Since Unix -> Unix is very simple, I'm starting with a patch that just does that. Happy to augment/rewrite this based on feedback.
The linked file in libtest specifically only supports stdout. If we're doing this to support terminal applications, I think it would be strange to support one but not all 3 of the standard streams.
The `atty` crate contains a bunch of extra logic that libtest does not contain, in order to support MSYS terminals: https://github.com/softprops/atty/commit/db8d55f88eabfcc22cde39533c2b1d688d1cdfc6 so I think if we're going to do Windows support, we should probably access all that logic somehow. I think it's pretty clear that the implementation is not going to change, so I think if we want to, pasting the contents of the `atty` crate into Miri is on the table, instead of taking a dependency.
I benchmarked this and as far as I can see the difference to the old code is totally within noise. And this makes the code a lot simpler and removes duplication so yay. :)
Make "./miri {build,run,test}" use debug assertions but "./miri install" not
This makes `./miri run`/`./miri test` use the full set of debug assertions (including the rather expensive ones that check consistency of the Stacked Borrows cache), but `./miri install` installs a Miri *without* those debug assertions.
That's the same behavior as cargo, and helps catch Miri bugs with the test suite while making installed Miri usable for larger runs.
move checking ptr tracking on item pop into cold helper function
Before:
```
Benchmark 1: cargo miri run --manifest-path bench-cargo-miri/serde1/Cargo.toml
Time (mean ± σ): 6.729 s ± 0.050 s [User: 6.608 s, System: 0.124 s]
Range (min … max): 6.665 s … 6.799 s 5 runs
Benchmark 2: cargo miri run --manifest-path bench-cargo-miri/unicode/Cargo.toml
Time (mean ± σ): 20.923 s ± 0.271 s [User: 20.386 s, System: 0.537 s]
Range (min … max): 20.580 s … 21.165 s 5 runs
```
After:
```
Benchmark 1: cargo miri run --manifest-path bench-cargo-miri/serde1/Cargo.toml
Time (mean ± σ): 6.562 s ± 0.023 s [User: 6.430 s, System: 0.135 s]
Range (min … max): 6.544 s … 6.594 s 5 runs
Benchmark 2: cargo miri run --manifest-path bench-cargo-miri/unicode/Cargo.toml
Time (mean ± σ): 20.375 s ± 0.228 s [User: 19.964 s, System: 0.413 s]
Range (min … max): 20.201 s … 20.736 s 5 runs
```
Nothing major, but we'll take it I guess. :shrug:
Auto merge of #2352 - saethlin:new-benchmark, r=RalfJung
Add a benchmark of the hang-on-test-failure code path
This is the code pattern that produces the performance problem in https://github.com/rust-lang/miri/issues/2273
I figured out what I was stuck on in https://github.com/rust-lang/miri/pull/2315#discussion_r916387919. For a while I was just doing `let x: &[u8] = &[0u8; 4096];` but that doesn't produce the runtime inside `Stack::item_popped` that I was looking for, I think because this allocation is never deallocated. But with `Vec`, I get the profile I'm looking for.