-
Notifications
You must be signed in to change notification settings - Fork 355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
miri test and #[should_panic] #636
Comments
Yea this definitely makes sense to not run these tests until we figure out how to do unwinding. Unfortunately we are not running the tests manually. Instead, rustc generates a boatload of boilerplate that we then execute. It would be very hard and fragile to extract the relevant information to realize we can't possibly run this test and then report to the boilerplate that said test was ignored/failed/succeeded |
Well, one thing we could try to do is change the libtest harness to not execute |
I think a less miri-specific variant would be to add a flag to ignore |
Good idea! It should be straightforward to add (at least, appears so after looking at libtest). First, add a field Then. check for the Set tests to ignore if they match ignore_should_panic in Make a test for the configuration. Add a description to the cli's ui. After that works and is merged into rustc's libtest, pass the flag by default in cargo miri's test command and mention the behavior in the readme. Line 342 in e9be422
|
…=oli-obk Add unstable option to ignore should_panic tests Add an unstable option `--exclude-should-panic` to libtest to workaround rust-lang/miri#636 ?r @oli-obk cc @RalfJung
Add unstable option to ignore should_panic tests Add an unstable option `--exclude-should-panic` to libtest to workaround rust-lang/miri#636 ?r @oli-obk cc @RalfJung
has been working out like a charm! Two possible options from here:
|
As discussed on zulip, rustdoc and miri don't work together anyway, so having some nice should_panic support for doc comments can be done once we work on running miri on rustdoc code examples. |
That seems like a reasonable approach to me. The argument computation code begins here. |
I just ran into this. Let me know if there is anything I can do on the libtest side to help here. We wanted to rework the libtest macros (like |
Yes. The issue i'm raising is that |
Okay. That would be the newly created #658 then. |
I've been running miri on various crates, including foundational ones on crates.io.
Currently, running
cargo +nightly miri test
on a test that is expected to panic, e.g.causes miri to stop the tests early and printing the following (in addition to a sizeable trace)
It would be convenient if miri took account of the
#[should_panic]
attribute, allowing miri to continue on with other tests. It's trivial to add#[cfg(not(miri))]
, but the tests continuing to run might be expected by new users of miri.If the current behaviour is expected or if the attribute is out of reach of miri, feel free to close ^^
The text was updated successfully, but these errors were encountered: