Possible panic safety issues in prune and insert_item

[ammaraskar]

Hi there, we (Rust group @sslab-gatech) are scanning crates on crates.io for potential soundness bugs. We noticed some panic safety issues in the prune and insert_item functions:

topq/src/lib.rs

Lines 163 to 174 in 8cc1e75

	if idx_good {
	// No need to copy if we are already here
	if good != idx {
	// Drop the destination item
	core::ptr::drop_in_place(good_ptr);
	// Move from source to destination
	core::ptr::copy_nonoverlapping(idx_ptr, good_ptr, 1);
	}
	// Move to the next good position
	good += 1;

topq/src/lib.rs

Lines 106 to 114 in 8cc1e75

	match result_idx {
	Ok(idx) => {
	unsafe {
	// We have an exact priority match. Drop the old item and
	// replace it with the new.
	core::ptr::drop_in_place(start_ptr.add(idx));
	core::ptr::write(start_ptr.add(idx), new_item);
	}
	}

This isn't too big of an issue right now because Topq currently leaks memory when it goes out of scope because the queue is wrapped in MaybeUninit. However, this can lead to double-frees if Topq was updated to free the memory or if someone called these methods indirectly through their drop code.

Namely, if the user provided type T panics during the drop_in_place operations, the Topq can be left in an inconsistent state and when it unwinds it can cause the same element to be dropped again.