-
Notifications
You must be signed in to change notification settings - Fork 356
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
Abort in "assert_*" intrinsics #1222
Comments
Might make more sense to name the intrinsics e.g |
…,eddyb rename panic_if_ intrinsics to assert_ [Suggested by @eddyb](rust-lang/miri#1222 (comment))
…,eddyb rename panic_if_ intrinsics to assert_ [Suggested by @eddyb](rust-lang/miri#1222 (comment))
Had a medical procedure, so sadly I'll only be able to work on it in a few days |
No worries, this is not urgent at all. :) Get well soon! |
How should I modify these tests to capture the aborts? (maybe I can "patch" the abort function so I can catch it? but it might defeat the purpose) We could also Another option would be to hook on SIGABRT and loop there, and launch a separate thread per function so we can catch all aborts like that without the process being terminated something like: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4363a89d68c089f122fd06cd37598a75 just remembered miri doesn't support threading yet |
Just remove these things from the |
These three intrinsics should, IMO, abort instead of panic. The main reason we make them panic in rustc is that we want a good backtrace, and doing that from codegen is hard. But causing a panic is easy thanks to libcore having panic support, and std hooking into it.
But in Miri, we can show great backtraces on abort! So, there is no reason to use panics IMO. So I propose that we extend this with an abort message:
miri/src/eval.rs
Line 56 in 704228d
and then cause an abort from the intrinsic.
@elichai that they would look into this.
The text was updated successfully, but these errors were encountered: