zygoloid wrote: > I'm not sure what semantics are being applied here.
My understanding is the semantics that are being applied here after the most recent fix are strictly about *objects*, not about *storage*. At the point where the lifetime of an object of type `T` ends, we are no longer required to preserve the value stored in that object. And so we can treat the contents of that object as "becoming `undef` / `poison`" (being dead) at the point where the destructor completes. `operator delete` isn't involved in this in any way, except that at the ABI level there is a "deleting destruction" operation that combines a destructor with an invocation of `operator delete`, and we inaccurately internally think of the combined function as being a destructor. This led to a bug where we'd accidentally mark the object as being dead too late -- after the `operator delete` ran, at the end of the deleting destructor, instead of after the end of the actual destructor and before the `operator delete` call. > Alternatively we would say that all allocators must call `new (ptr) <Internal > type>(..)` to re-start the lifetime of the memory as the internal allocator > object, and then run that destructor prior to returning a pointer from > operator new. Formally, yes, that would be required by the C++ object model. But Clang doesn't currently implement the object model with that degree of pedantry, and instead allows implicit object creation much more broadly than the standard requires. https://github.com/llvm/llvm-project/pull/183347 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
