Undetected use after move

[pepijndevos]

So I was curious how Drop handles cycles, because this could lead to dangling pointers, which is why __del__ might not be called in Python. And indeed the below example does not call Drop.

But t is moved into u, so why does this compile at all?

struct Test {
    a: int,
    b: Option<Box<Test>>,
}

impl Drop for Test {
    fn drop(&mut self) {
        println!("Dropping {}", self.a);
    }
}

fn stuff() {
    let mut t = Test { a: 1, b: None};
    let mut u = Test { a: 2, b: Some(box t)};    
    t.b = Some(box u);
    println!("done");
}

fn main() {
    stuff();
    println!("Hello, world!")
}

[alexcrichton]

Nominating, seems like a soundness hole.

[arielb1]

This is an issue with zeroing dynamic drops (which are going to be removed: rust-lang/rfcs#320) – when t is moved, its drop flag is cleared, which prevents the destructor of t.b from running.

A clearer example is:

struct Test;

struct Test2 {
    b: Option<Test>,
}

impl Drop for Test {
    fn drop(&mut self) {
        println!("Dropping");
    }
}

#[cfg(leaks)]
impl Drop for Test2 {
    fn drop(&mut self) {}
}

fn stuff() {
    let mut t = Test2 { b: None };
    let u = Test;
    drop(t);
    t.b = Some(u);
}

fn main() {
    stuff();
}

[nikomatsakis]

Structs that implement drop are not supposed to be in a partially initialized state. We already prevents moves out from individual fields, but we also need to prevent individual fields from being re-initialized.

cc @zwarich since (iirc?) he was working on the patches that made us more accepting around re-initializing fields and so forth, and maybe this bug is of interest to him.

[pnkfelix]

So we are not supposed to allow structs that implement drop to be partially initialized.

We already disallow going from fully-initialized to partially initialized.

But it seems (from the first example) that we missed disallowing going from fully-uninitialized to partially initializd. That needs to be fixed.

Assigning P-backcompat-lang, 1.0.

[pnkfelix]

While this will hopefully be fixed soon, as there is a PR up, it seems to have fallen through the cracks as a P-backcompat-lang issue that is only on the 1.0 milestone and not 1.0 beta.

Nominating for 1.0 beta. (Also, I guess I will try to run through and find any other such overlooked issues.)