Change:
//! This is handled by the [`InPlaceDrop`] guard for sink items (`U`) and by //! [`vec::IntoIter::forget_allocation_drop_remaining()`] for remaining source items (`T`). //! <ins> //! If dropping any remaining source item (`T`) panics then [`InPlaceDstBufDrop`] will handle dropping //! the already collected sink items (`U`) and freeing the allocation. //! </ins> //! [`vec::IntoIter::forget_allocation_drop_remaining()`]: super::IntoIter::forget_allocation_drop_remaining() //! //! # O(1) collect

Discussion:
I tried this code: I expected to see this happen: The drop implementation for and is called. Instead, this happened: Everything that was mapped and the allocation was leaked. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: I discovered this issue when I learned that re-uses a allocation if possible. Which prompted me to read the code. Running the example with also reports the memory leak. And changing to no longer displays the memory leak. This is what I think happens: While dropping the call in panics. Then is being dropped, but honestly I don't really understand why. My understanding is that should unwind. If anyone can explain this, please do so. Then as part of unwinding is dropped, but it has its fields set to an empty buffer of len 0, so it does nothing. Note, I suspect more optimal code gen could be achieved by using to avoid generating code for the drop that will never do anything after we cleared the fields. The two created will never get dropped, thus leading to the memory leak. Plus the main allocation, previously owned by as stored in will be leaked too. Because it was cleared in and assumed to be taken over by but we never reached that point. Proposed solution, a drop guard in that guards the call and would drop the head in this case and the backing allocation if panics.
Tagging because of your work on and the associated PRs.
Nice find! Technically this is a regression. label regression-from-stable-to-stable, T-libs. It works properly until 1.47, it double-frees and then aborts (thread panicked while panicking; presumably because of double-freeing , too) in 1.48 through 1.51, and the current behavior is since 1.52 (all tested on godbolt, with the direct usage of variables in format strings fixed).
I haven’t looked at the code yet myself to figure out what’s going on.

In the meantime, I think that bisecting what changes were relevant for the regression 1.47 to 1.48 on one hand, and the point between 1.51 and 1.52 that appeared to have fixed the double-free (but introduced or kept (hard to tell with the abort) the memory leak) could be interesting. label E-needs-bisection. ^^
Doing the bisection. First one is second one is label -E-needs-bisection
So that’s likely and . Let me tag who might be more familiar with the code at hand since they were involved with both PRs :-)
I’m not sure if I’m reading the PR description of correctly as in that this leak might be intentional? (If it is intentional, I haven’t understood the rationale yet though…) I mean… who knows, maybe this is talking about something entirely different than what this issue is about ^^
Looking at the code, this leak seems relatively easy to avoid. Assuming that dropping the elements while unwinding will itself not panic. I'm guessing the comment you reference relates to something else. Also any idea why and how gets dropped?
The relevant piece of code seems to be this one: Where is defined here: So what happens is: all the elements to collect have been written however there could be more element in the original / moreover we want to give ownership of the allocation to the new so we remove any reference to the original allocation from the and we drop the remaining elements finally, we create the that logically owns both the and the allocation The problem is that a panic can occur while dropping the remaining elements, and in that case we didn't yet create the final , so nothing is responsible for dropping the allocation (which was already removed from the New`s. The simpliest fix would be to create the before dropping the remaining elements, however I'm not sure if that's correct with respect to aliasing/stacked borrows. For example if is ever implemented using internally then it would claim unique access to the allocation, which invalidates the pointer used to drop the remaining elements. I think the most robust solution would be a drop guard that frees the allocation and the s on drop (and is forgotten before creating the actual that's returned). Dropping the old elements is done with which will try to drop all the elements even if one panics while being dropped.

If another element's destructor panics then that's a panic while panicking and the program aborts.
keeps going and then rethrows the panic. That's because it replicates the . Yeah, to fix the double-drop in , this was the simplest solution that didn't require any extra parts. And if you're panicing in drop then leaks are allowed behavior. Avoiding them is more a QoI thing.
A bigger concern imo is... well... panic-safety. If the and the exist at the same time then you need to be really sure that panics can only occur after the IntoIter has given up the allocation. If a panic occurs between materializing the and before calling then you get double-frees again.
The idea was to create it right before calling
That could work. At least I'm not seeing anything that would go wrong with that given current implementations. The question is whether it's worth it adding yet another unsafe wrinkle to this goldberg machine.
~I think the issue will be type confusion. Which is what I initially looked for. If dropping those remaining Old elements panics, it would drop Olds as News. I think a simple drop guard before forget_ should do the trick.~ Never mind I got confused.
I think the issue will be type confusion. Which is what I initially looked for. If dropping those remaining Old elements panics, it would drop Olds as News. I think a simpel drop guard before forget_ should do the trick.