-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Closed
Labels
A-collectionsArea: `std::collections`Area: `std::collections`C-bugCategory: This is a bug.Category: This is a bug.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Description
STR:
use std::collections::VecDeque;
struct D(u8, bool);
impl Drop for D {
fn drop(&mut self) {
println!("Drop {}", self.0);
if self.1 {
panic!("panic in `drop`");
}
}
}
fn main() {
let mut q = VecDeque::new();
q.push_back(D(0, false));
q.push_back(D(1, false));
q.push_back(D(2, false));
q.push_back(D(3, false));
q.push_back(D(4, false));
q.push_front(D(100, false));
q.push_front(D(101, false));
q.push_front(D(102, true));
}
Output:
Drop 102
thread 'main' panicked at 'panic in `drop`', test.rs:9:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
Drop 101
Drop 100
Caused by the Drop
impl of VecDeque
:
rust/src/liballoc/collections/vec_deque.rs
Lines 146 to 154 in 90b957a
fn drop(&mut self) { | |
let (front, back) = self.as_mut_slices(); | |
unsafe { | |
// use drop for [T] | |
ptr::drop_in_place(front); | |
ptr::drop_in_place(back); | |
} | |
// RawVec handles deallocation | |
} |
Apparently drop_in_place
will continue dropping elements when one destructor panics. That doesn't carry over to the second call, of course.
Metadata
Metadata
Assignees
Labels
A-collectionsArea: `std::collections`Area: `std::collections`C-bugCategory: This is a bug.Category: This is a bug.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.