Closed e00E closed 4 months ago
Please keep in mind that the contents of loom::model
generally runs many times to try all different ways that the threads can be interleaved. It doesn't just run once.
Because of that, #[should_panic]
tests are out of scope for loom.
You may be able to use catch_unwind
to catch the panic inside the loom test, and then assert that a panic happened.
There are a bunch of should_panic
tests in loom's own test suite. I ran into this issue through one of those tests. If should_panic
isn't supported, then we should rewrite them.
To be more precise, I think you're saying that panicking across loom::model
isn't supported. Could we document that?
Oh, I see, they are loom's own tests. That's a different problem then. It's a known problem that loom will double-panic in some situations. It sounds like the UnsafeCell::drop
change is introducing more. That's okay. You can remove the offending test.
The expected result of this test is that it passes because it is marked
should_panic
and explicitly panics.The actual result is that the test aborts because a second panic occurs during unwinding of the first, explicit panic. The second panic is a bug.
The bug does not occur in the following variations:
S
is still dropped in the main thread during unwinding.S
is created in the spawned thread instead of moving there.I ran into this while working on https://github.com/tokio-rs/loom/issues/349 .