Allow destructors to be run directly on a memory location, so it is not impossible to handle location-dependent values

[rust-highfive]

Issue by huonw
Monday Aug 04, 2014 at 12:52 GMT

For earlier discussion, see rust-lang/rust#16242

This issue was labelled with: in the Rust repository

---

Currently, the only way for a library to run a destructor on a value is to let it fall out of scope while on the stack, that is, types wrapping raw pointers (like Vec and Rc) have to call ptr::read and let the resulting value drop to destroy their contents. This moves values in memory, and thus makes it literally impossible to use Vec or Rc (or any other library defined container type) for types with destructors that depend on the location of the value in memory.

This could be avoid we had a destroy_directly(&mut T) intrinsic that destroyed that memory location, and so what is currently written ptr::read(x) (or drop(ptr::read(x))) would be written destroy_directly(&mut *x) and (for types with Drop impls) effectively be just calling (&mut *x).drop().

e.g. https://github.com/rust-lang/rust/blob/795f6ae829ab1bfd72394a5da9096e2717ec0f62/src/libcollections/vec.rs#L1539 (there's a variety of other ptr::reads for a similar purpose in this file, and in other low-level code).

As a real-world example, putting a series of std::comm::Handle into a preallocated Vec (to satisfy the requirement that they must not move in memory after calling .add) will still break, because the destructors asserts that the memory address is the same as it was and thus Vec moving things in memory upsets it. The value being location dependent is bad, but it seems very reasonable to just destroy things in place to allow it to mostly work (it's probably more efficient too, since I believe LLVM can't optimise away the memcpy out of the Vec in all situations).

(NB. one can currently work-around this by box-ing everything, because the compiler-magic of the Box type means its destructor destroys things in-place.)

[Diggsey]

Shouldn't "destroy_directly" take a raw pointer rather than a reference? A reference implies the value is being borrowed, which isn't the case here.

[huonw]

I originally gave it that signature to match drop, however I do think the semantics we want here are reasonably close to &mut (wrt aliasing and uniqueness).

[scottmcm]

This seems to be https://doc.rust-lang.org/nightly/std/ptr/fn.drop_in_place.html, so closing.