-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Tracking Issue for PanicInfo::can_unwind #92988
Comments
Just thought of this, what happens if the panic handler actually unwind? If it can cause undefined behaviour then the panic handler would have to be unsafe. |
Unwinding is itself an unsafe operation. It is your responsibility to check that unwinding is actually possible before throwing an exception. |
That'll break encapsulation. There is no way that code can check that unwinding isn't currently in progress. |
That's what the |
However there're no ways to prevent the panic handler from calling another function that unwinds. So either panic handler needs to be unsafe to take that responsibility, or it implies that |
I just had a look through the code. By marking the This can be avoided by having a thread-local flag in the panic handler that catches recursive calls and aborts immediately. The standard library panic handler does this. |
Or probably just tweak the codegen to generate trap instead of |
Feature gate:
#![feature(panic_can_unwind)]
This is a tracking issue for
PanicInfo::can_unwind
.This function returns whether the panic handler is allowed to unwind the stack from the point where the panic occurred.
This is true for most kinds of panics with the exception of panics caused by trying to unwind out of a
Drop
implementation or a function whose ABI does not support unwinding.Public API
Steps / History
Unresolved Questions
The text was updated successfully, but these errors were encountered: