Fn unboxed closures can incorrectly mutate upvars

[bkoropoff]

The following program will write to freed memory:

#![feature(unboxed_closures, overloaded_calls)]

fn main() {
    let mut v = vec![];
    let ref f = |&:| { v.push(0u); v.get_mut(0) };
    let x = (*f)();
    for _ in range(0u, 5) {
        (*f)();
    }
    *x = 42u;
}

Borrowck needs to consider upvars in capture-by-ref, self-by-ref unboxed closures to be aliasable so that mutation and mutable borrows are rejected. I'm working on a patch to do this.

[zwarich]

This looks like the unboxed closure version of #17403. The comment by @nikomatsakis there suggests that the correct fix is a bit deeper than just requiring the upvars to be aliasable.

[bkoropoff]

I think there may be multiple issues. Right now unboxed closures permit the moral equivalent of mutating through an &&mut. It seems like borrowck should reject this out of hand regardless of the regions involved. I'm still new to the compiler, though, so I could be totally off here.

[zwarich]

@bkoropoff I meant that after your proposed fix there might be other soundness problems with unboxed closures, based on the fact that the inferred regions seem incorrect, but playing around for a bit I can't get any of them to happen.

[bkoropoff]

The following presently builds:

#![feature(unboxed_closures, overloaded_calls)]

fn main() {
    let mut x = 0u;
    let _f = |&:| x = 42;
}

However, this is equivalent to writing:

struct F<'a> {
    x: &'a mut uint
}

impl<'a> Fn<(),()> for F<'a> {
    #[rust_call_abi_hack]
    fn call(&self, _: ()) {
        *self.x = 42; // error: cannot assign to data in a `&` reference
    }
}

fn main() {
    let mut x = 0u;
    let _f = F { x: &mut x };
}

The key is that call takes self immutably, which means the closure can be invoked through an immutable reference and wreak havoc. Boxed closures can't be called through immutable references, so there isn't a problem here.

My patch fixes this, but it does not address the region issue. I'll retitle the bug to make it clear that it only covers this unboxed-closure-specific issue.

[zwarich]

A variation of this example causes an ICE: #17786