Unsoundness when dropping cycles with custom `Drop` implementation about dumpster

[claytonwramsey]

My original idea for handling this was covered in a remark in Collectable - in essence, buyer beware - with Collectable as an unsafe trait. I think that the approach of forcing a Drop implementation on all Collectable types is far more elegant, though. Will do.

[claytonwramsey]

@wishawa By the way, do you know any elegant way to extract a TokenStream for the "default" implementation of Drop, or do I have to go do that myself?

[claytonwramsey]

A possible wrinkle: in your example solution, MyStructInner would have to be either !Collectable or have a manual implementation of Collectable. An alternate solution would be to make Gc operations panic if dereferenced during Drop.

[wishawa]

@wishawa By the way, do you know any elegant way to extract a TokenStream for the "default" implementation of Drop, or do I have to go do that myself?

The "default" implementation of drop is just

impl Drop for Type {
fn drop(&mut self) {}
}

right?

But if you meant the drop glue, I have no idea. I don't know if it even exists as Rust code (as opposed to being some intermediate representation thing).

[wishawa]

A possible wrinkle: in your example solution, MyStructInner would have to be either !Collectable or have a manual implementation of Collectable.

True. I didn't think of that. One fix would be to provide a mostly transparent ManuallyCollectable type analogous to std::mem::ManuallyDrop.

An alternate solution would be to make Gc operations panic if dereferenced during Drop.
This might be the cleanest way to go about it.

An issue is that with careful use of Pin, it is possible to safely make self-referential types that hold references derefed before the drop. I don't think there is a general fix for this. The good thing is this is almost impossible to unintentionally run in to.

[claytonwramsey]

I've now made it so that Gc::deref will panic if dereferenced against a value which is currently being dropped.