Miri tests
vorner opened this issue · 5 comments
Arc-swap contains non-trivial amount of unsafe code. It would be nice to be able to run it inside miri.
Nevertheless, miri doesn't have threads (yet?). So the current tests aren't really applicable. Also, some of the test dependencies can't be compiled under miri.
Examine how far we can get by writing some lighter-weight single-threaded tests as a subcrate, without all that fancy testing dependencies.
I got an error in CI which seems to be caused by this issue.
https://github.com/Manishearth/triomphe/pull/7/checks?check_run_id=581436165
associated PR: Manishearth/triomphe#7
CI log snippet
2020-04-12T23:55:14.8305578Z error: unsupported operation: can't call foreign function: llvm.x86.sse2.pause
2020-04-12T23:55:14.8306231Z --> /usr/share/rust/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/../stdarch/crates/core_arch/src/x86/sse2.rs:25:5
2020-04-12T23:55:14.8306698Z |
2020-04-12T23:55:14.8307145Z 25 | pause()
2020-04-12T23:55:14.8307611Z | ^^^^^^^ can't call foreign function: llvm.x86.sse2.pause
2020-04-12T23:55:14.8307861Z |
2020-04-12T23:55:14.8308072Z = help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support
2020-04-12T23:55:14.8312403Z = note: inside `std::arch::x86_64::_mm_pause` at /usr/share/rust/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/../stdarch/crates/core_arch/src/x86/sse2.rs:25:5
2020-04-12T23:55:14.8313373Z = note: inside `std::hint::spin_loop` at /usr/share/rust/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/hint.rs:76:22
2020-04-12T23:55:14.8314364Z = note: inside `std::sync::atomic::spin_loop_hint` at /usr/share/rust/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/sync/atomic.rs:149:5
2020-04-12T23:55:14.8315561Z = note: inside `arc_swap::ArcSwapAny::>::wait_for_readers` at /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/arc-swap-0.4.5/src/lib.rs:1009:17
2020-04-12T23:55:14.8316314Z = note: inside `> as std::ops::Drop>::drop` at /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/arc-swap-0.4.5/src/lib.rs:700:9
2020-04-12T23:55:14.8317226Z = note: inside `std::intrinsics::drop_in_place::>> - shim(Some(arc_swap::ArcSwapAny>))` at /usr/share/rust/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/ptr/mod.rs:177:1
2020-04-12T23:55:14.8317566Z note: inside `tests::arc_swap_` at lib.rs:1193:30
2020-04-12T23:55:14.8317941Z --> lib.rs:1193:30
2020-04-12T23:55:14.8318137Z |
2020-04-12T23:55:14.8318321Z 1193 | let _ = x.clone();
2020-04-12T23:55:14.8318512Z | ^
2020-04-12T23:55:14.8318694Z note: inside closure at lib.rs:1185:5
2020-04-12T23:55:14.8319026Z --> lib.rs:1185:5
2020-04-12T23:55:14.8319225Z |
2020-04-12T23:55:14.8319406Z 1185 | / fn arc_swap_() {
2020-04-12T23:55:14.8319643Z 1186 | | type ArcSwap = arc_swap::ArcSwapAny>;
2020-04-12T23:55:14.8319843Z 1187 | |
2020-04-12T23:55:14.8320059Z 1188 | | let mut canary = atomic::AtomicUsize::new(0);
2020-04-12T23:55:14.8320236Z ... |
2020-04-12T23:55:14.8320421Z 1195 | | assert_eq!(canary.load(Acquire), 1);
2020-04-12T23:55:14.8320611Z 1196 | | }
2020-04-12T23:55:14.8320788Z | |_____^
2020-04-12T23:55:14.8321540Z = note: inside `<[closure@lib.rs:1185:5: 1196:6] as std::ops::FnOnce<()>>::call_once - shim` at /usr/share/rust/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/ops/function.rs:232:5
Hello
I suspect some confusion here. I don't see how the wish to be able to run miri in arc-swap's CI might in any way be related to a CI failure in some completely different crate.
Can you explain?
I added support for arc-swap in triomphe behind a feature flag.
Thanks for that, it's a great news.
Nevertheless, I still don't understand what you're trying to report here. This issue is about expanding arc-swap's tests. Which hasn't happened. The existence or non-existence of some tests can't in any reasonable way influence your CI.
I guess you might be complaining that arc-swap (not only its tests) doesn't work under miri. If that's so, I'd open a separate issue for that. Nevertheless, I'm not sure if it should be fixed on the arc-swap side or miri side or if it should be declared „out of scope“ of each, since arc-swap is inherently a thread synchronization primitive and miri doesn't like threads.
If you're trying to say something different than this, then please explain it more clearly.
I guess
You guessed correctly. I disabled miri for the arc-swap+triomphe test for now, but I keep an eye on this (and related) issues.