-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vec dtor might want to try harder on failure #16135
Comments
This is... disturbing. We also discovered today that In general it sounds like our "clean up on destructor failure" story isn't so hot when considering issues like #14875 as well. |
I don't think it makes sense to take a further performance and complexity hit to improve (but not fix) support for something that's already broken. |
Triage: this sitll only prints |
Triage: #![feature(box_syntax)]
struct F(Box<()>);
impl Drop for F {
fn drop(&mut self) {
println!("drop");
panic!()
}
}
fn main() {
let _v = vec!(F(box ()), F(box ()), F(box ()), F(box ()));
} steve@warmachine:~/tmp$ ./main
drop
thread '<main>' panicked at 'explicit panic', main.rs:7
note: Run with `RUST_BACKTRACE=1` for a backtrace. |
Since we did the Vec / RawVec split, it should now be the case that the RawVec allocation itself is always free'd even if one of the elements panic in Vec's drop. Confirmed that it does deallocate the RawVec allocation using rustc 1.9.0-nightly (7b0b80a 2016-03-02). |
I believe we handle this correctly today, in that we attempt to deallocate all elements regardless of failure: struct F(u32);
impl Drop for F {
fn drop(&mut self) {
eprintln!("drop");
if self.0 == 0 { panic!() }
}
}
fn main() {
let _v = vec!(F(1), F(0), F(1), F(1));
}
|
… r=Veykril Refactor extension to support arbitrary shell command runnables Currently, the extension assumes that all runnables invoke cargo. Arguments are sometimes full CLI arguments, and sometimes arguments passed to a cargo subcommand. Refactor the extension so that tasks are just a `program` and a list of strings `args`, and rename `CargoTask` to `RustTask` to make it generic. (This was factored out of rust-lang#16135 and tidied.)
Allow rust-project.json to include arbitrary shell commands for runnables This is a follow-up on rust-lang#16135, resolving the feedback raised :) Allow rust-project.json to include shell runnables, of the form: ``` { "build_info": { "label": "//project/foo:my-crate", "target_kind": "bin", "shell_runnables": [ { "kind": "run", "program": "buck2", "args": ["run", "//project/foo:my-crate"] }, { "kind": "test_one", "program": "test_runner", "args": ["--name=$$TEST_NAME$$"] } ] } } ``` If these runnable configs are present for the current crate in rust-project.json, offer them as runnables in VS Code. This PR required some boring changes to APIs that previously only handled cargo situations. I've split out these changes as commits labelled 'refactor', so it's easy to see the interesting changes.
Although dtors should not fail (by convention), it can happen. The
Vec
dtor doesn't do anything to defend against one of its elements' failing.Since there's no winning when dtors fail, it's not obvious that
Vec
should try to do anything, but for comparison, the I/O process and stream types both take defensive measures to try to make the best of similar situations.This program leaks 4 boxes, the buffer, and fails to run 3 dtors:
The text was updated successfully, but these errors were encountered: