[Pre-RFC]: ExcDrop trait for different drop-glue during unwinding


@arielb1: Wouldn’t that be a breaking change?

@aidancully: Having read into how Drop is actually implemented, I think @comex is right – Drop code for structs and enums whose contents implement Drop is silently added by rustc. Adding another trait that needs to be supported would a) complicate the compiler (since you now could have code that implements Drop, but not DropExc, or vice versa), and generate a whole lot of code that is likely not needed most of the time, and cannot even be inlined or presumed dead.

If you care for rust on embedded systems (as you profess), you’ll be better off working towards linear types.


It would be, but the representation of drop-glue is unstable AFAIK. We could generate wrappers (fn drop_glue_noexpect(self) { self.drop_glue(false) }) (the real overhead is in the recursive calls anyway).

@llogiq I expect embedded code to not be using panics anyway (we would need a flag to rustc that disables ExcDrop).


I’ve never disputed that more code would be generated when this facility is used… My point is more that, by using this facility, a developer indicates that she wants different code to be executed during unwinding. Allowing multiple paths can mean more code, but that shouldn’t surprise anyone. @arielb1 identified a way to allow types that only implement Drop to avoid having multiple drop-glues generated, even when they contain fields that implement ExcDrop (thank you for that!), is this still a concern?

(I’m not sure I follow your point regarding trait objects - I didn’t think it was possible, or ever will be possible, for drop-glue to be called against a trait object? Even with &move pointers, allowing ownership to change hands along with the trait object, the drop-glue would probably need to be inserted by the caller, and invoked after the function that took ownership of the &move pointer returns… Am I wrong about that? How would the called function know that the concrete type implements Drop?)

I consider this part of that effort. I don’t expect linear types to be accepted in the language without addressing the concern that linear types don’t play well with unwinding. I’m trying to address that concern.

This is right. Well, to be more precise, embedded code will (probably) not use unwinding. Panics and assertions are critical in debug builds, but they will probably just stop the program from running, and enable post-mortem debug facilities. But in any case ExcDrop isn’t likely to be useful in embedded environments. (For what it’s worth, I’d prefer to use the word “freestanding” - i.e. talking to bare metal, no OS support - over “embedded” to describe this domain. The term “embedded” has more to do with how much control the user has over the software environment than it does with software capabilities directly…)


When Box<Trait> is freed…

Regarding an is_panic parameter - it adds some code size because you have to add an instruction to set it in every function that calls the drop glue. Maybe this isn’t significant.


OK, so one of the entries in the trait-object vtable is (apparently) the drop-glue function for the concrete type… Good to know.