A marker trait which represents "panic safe" types in Rust.
This trait is implemented by default for many types and behaves similarly in
terms of inference of implementation to the
Sync traits. The
purpose of this trait is to encode what types are safe to cross a
boundary with no fear of unwind safety.
In Rust a function can "return" early if it either panics or calls a function which transitively panics. This sort of control flow is not always anticipated, and has the possibility of causing subtle bugs through a combination of two critical components:
- A data structure is in a temporarily invalid state when the thread panics.
- This broken invariant is then later observed.
Typically in Rust, it is difficult to perform step (2) because catching a
panic involves either spawning a thread (which in turns makes it difficult
to later witness broken invariants) or using the
catch_unwind function in this
module. Additionally, even if an invariant is witnessed, it typically isn't a
problem in Rust because there are no uninitialized values (like in C or C++).
It is possible, however, for logical invariants to be broken in Rust,
which can end up causing behavioral bugs. Another key aspect of unwind safety
in Rust is that, in the absence of
unsafe code, a panic cannot lead to
That was a bit of a whirlwind tour of unwind safety, but for more information about unwind safety and how it applies to Rust, see an associated RFC.
Now that we've got an idea of what unwind safety is in Rust, it's also
important to understand what this trait represents. As mentioned above, one
way to witness broken invariants is through the
catch_unwind function in this
module as it allows catching a panic and then re-using the environment of
Simply put, a type
UnwindSafe if it cannot easily allow
witnessing a broken invariant through the use of
catch_unwind (catching a
panic). This trait is an auto trait, so it is automatically implemented for
many types, and it is also structurally composed (e.g., a struct is unwind
safe if all of its components are unwind safe).
Note, however, that this is not an unsafe trait, so there is not a succinct
contract that this trait is providing. Instead it is intended as more of a
"speed bump" to alert users of
catch_unwind that broken invariants may be
witnessed and may need to be accounted for.
Types such as
&mut T and
&RefCell<T> are examples which are not
unwind safe. The general idea is that any mutable state which can be shared
catch_unwind is not unwind safe by default. This is because it is very
easy to witness a broken invariant outside of
catch_unwind as the data is
simply accessed as usual.
&Mutex<T>, however, are unwind safe because they implement
poisoning by default. They still allow witnessing a broken invariant, but
they already provide their own "speed bumps" to do so.
It is not intended that most types or functions need to worry about this trait.
It is only used as a bound on the
catch_unwind function and as mentioned
above, the lack of
unsafe means it is mostly an advisory. The
AssertUnwindSafe wrapper struct can be used to force this trait to be
implemented for any closed over variables passed to