Code change:
// not covered via the Shared impl above b/c the inner contents use // Cell/AtomicUsize, but the usage here is recover safe so we can lift the // impl up one level to Arc/Rc itself <del> impl<T: NoUnsafeCell + ?Sized> RecoverSafe for Rc<T> {} impl<T: NoUnsafeCell + ?Sized> RecoverSafe for Arc<T> {} </del> <ins> impl<T: RefRecoverSafe + ?Sized> RecoverSafe for Rc<T> {} impl<T: RefRecoverSafe + ?Sized> RecoverSafe for Arc<T> {} </ins> <del> // Pretty simple implementations for the `NoUnsafeCell` marker trait, basically // just saying that this is a marker trait and `UnsafeCell` is the only thing // which doesn't implement it (which then transitively applies to everything // else. impl NoUnsafeCell for .. {} impl<T: ?Sized> !NoUnsafeCell for UnsafeCell<T> {} </del> <ins> // Pretty simple implementations for the `RefRecoverSafe` marker trait, // basically just saying that this is a marker trait and `UnsafeCell` is the // only thing which doesn't implement it (which then transitively applies to // everything else. impl RefRecoverSafe for .. {} impl<T: ?Sized> !RefRecoverSafe for UnsafeCell<T> {} impl<T> RefRecoverSafe for AssertRecoverSafe<T> {} </ins> impl<T> AssertRecoverSafe<T> { /// Creates a new `AssertRecoverSafe` wrapper around the provided type.

Related discussion:
text: Test Case 1: Test Case 2: Both produce errors like this: CC
Hm, so the first case here should work (e.g. should subvert basically everything), although the second case is correct in yielding an error (albeit not a very good one)
Is the second case not allowed then? 's documentation suggests that manually implementing it is okay to do: I figured only existed to wrap types which you couldn't yourself, but for which you can ensure their invariants are upheld across the boundary. And what about moving values into the closure? can't be unwrapped, at least not currently.
Oh wait sorry I misread your second example, I failed to notice the manual ! This is basically a case where closure captures are coming into play. The closures aren't annotated with , so outer variables are captured by-reference which means that the actual types being tested against the trait here are and . In the first case that should be handled by , but the second is legitimately indicating that it's not a recover-safe type (b/c the reference is different than the by-value). You should be able to get around this via either plus or via . Certainly an interesting interaction going on here though. One would likely expect that if isn't recover safe that would fix the problem but it's likely what you really need to do is due to the way closures largely work.
There's , why not ? Coherence?
Nah unfortunately that'd defeat the purpose of the distinction. The type is itself recover safe, it's just that's not (so the distinction need to be there)
It's unfortunate that fails due to coherence or something like that:
Hm interesting, I guess yeah you'll be forced to move the reference inside the wrapper rather than having a reference to the wrapper
Is it possible to implement then? My use case can contain and friends but I'm guaranteeing that they're unobservable in user code after recovery because I immediately re-panic after escaping the FFI stack.
I guess I can just use once it's fixed :stuckouttongue:. I see your PR has been accepted so I'll look forward to trying it on tonight's nightly. When do the buildbots fire?
Yeah currently you can implement (being renamed to ) I believe (although I can't say I've tried). For now though yeah I'd recommend just using plus closures.