break stmt confuses intialization-knowledge of borrow checker

[pnkfelix]

This code should not compile:

demo code courtesy of niko's comment below.

struct Foo { n0: i32, n1: i32 }

fn leak_1_brk() -> Foo {
    let ret;
    loop {
        ret = Foo { n0: { break }, n1: 22 };
    }
    // (`ret` is still uninitialized here!)
    ret
}

fn main() { }

Original report:

I was making regression tests for #21486 and ran into this, though @nikomatsakis has pointed out that it is not specific to FRU.

Test case 1:

use std::sync::atomic::{Ordering, AtomicUsize, ATOMIC_USIZE_INIT};

#[derive(Debug)]
struct Noisy(u8);
impl Drop for Noisy {
    fn drop(&mut self) {
        // println!("splat #{}", self.0);
        event(self.0);
    }
}

#[allow(dead_code)]
#[derive(Debug)]
struct Foo { n0: Noisy, n1: Noisy }
impl Foo {
    fn vals(&self) -> (u8, u8) { (self.n0.0, self.n1.0) }
}

fn leak_1_brk() -> Foo {
    let _old_foo = Foo { n0: Noisy(1), n1: Noisy(2) };
    let ret;
    loop {
        ret = Foo { n0: { break }, .._old_foo };
    }
    // ret has not been initialized!!!!!
    ret
}

pub fn main() {
    reset_log();
    // Note: there's not much that's reasonable to expect here...
    let value = leak_1_brk().vals();
    assert_eq!(0x01_02, event_log());
    assert_eq!(value, (1,2));
}

static LOG: AtomicUsize = ATOMIC_USIZE_INIT;

fn reset_log() {
    LOG.store(0, Ordering::SeqCst);
}

fn event_log() -> usize {
    LOG.load(Ordering::SeqCst)
}

fn event(tag: u8) {
    let old_log = LOG.load(Ordering::SeqCst);
    let new_log = (old_log << 8) + tag as usize;
    LOG.store(new_log, Ordering::SeqCst);
}

Test case 2:

use std::sync::atomic::{Ordering, AtomicUsize, ATOMIC_USIZE_INIT};

#[derive(Debug)]
struct Noisy(u8);
impl Drop for Noisy {
    fn drop(&mut self) {
        // println!("splat #{}", self.0);
        event(self.0);
    }
}

#[allow(dead_code)]
#[derive(Debug)]
struct Foo { n0: Noisy, n1: Noisy }
impl Foo {
    fn vals(&self) -> (u8, u8) { (self.n0.0, self.n1.0) }
}

fn leak_1_brk() -> Foo {
    let _old_foo = Foo { n0: Noisy(1), n1: Noisy(2) };
    let ret;
    loop {
        ret = Foo { n0: { break }, n1: { break } };
    }
    // !!!!!
    ret
}


pub fn main() {
    reset_log();
    // Note: there's not much that's reasonable to expect here...
    assert_eq!(leak_1_brk().vals(), (1,2));
    assert_eq!(0x01_02, event_log());
}

static LOG: AtomicUsize = ATOMIC_USIZE_INIT;

fn reset_log() {
    LOG.store(0, Ordering::SeqCst);
}

fn event_log() -> usize {
    LOG.load(Ordering::SeqCst)
}

fn event(tag: u8) {
    let old_log = LOG.load(Ordering::SeqCst);
    let new_log = (old_log << 8) + tag as usize;
    LOG.store(new_log, Ordering::SeqCst);
}

[nikomatsakis]

Here is a vastly reduced test case:

http://is.gd/EtaDNZ

struct Foo { n0: i32, n1: i32 }

fn leak_1_brk() -> Foo {
    let ret;
    loop {
        ret = Foo { n0: { break }, n1: 22 };
    }
    ret
}

fn main() { }

[pnkfelix]

triage: P-high (1.0)

[apasel422]

An example not involving fields:

fn consume(bar: Box<i32>) {
    println!("{:?}", x);
}

fn main() {
    let mut foo = Box::new(1);
    loop {
        foo = { consume(foo); break };
    }
    consume(foo);
}

[apasel422]

I've actually been exploiting this here: https://github.com/apasel422/tree/blob/master/src/node/mod.rs#L254-L269. It's only "worked," apparently, because there is no implementation of Drop for the types involved, which are references.

[pnkfelix]

Based on some cursory investigation, my current hypothesis is that there is a bug in rustc::middle::dataflow, or at least in the interaction between rustc::middle::cfg and rustc::middle::dataflow.

In particular, we have a method, add_kills_from_flow_exits, which is meant to gather all of the effects that need to occur due to a non-local control transfer (like that of break), based on the scopes that it pops through, and assign those effects to the transfer-function attached to the break.

The problem is that it does this by taking the union of all of the kill-effects for every node in the exiting_scopes associated with that edge in the control-flow graph, and even the assignment expression is in the exiting_scopes list. So we end up including the kill-effect of the assignment (which in this case I think kills the record that foo is in the "moved-away" set), and so we end up thinking that foo is initialized in the successor node of the break in the control-flow.

Its possible the fix here may be simple. Not sure yet.

[ftxqxd]

Minimal:

fn main() {
    let x: i32;
    loop {
        x = break;
    }
    println!("{}", x);
}