Calling a closure needs to be treated like a unique-immutable borrow

[nikomatsakis]

We made closures linear so as to help prevent recursion, but the other part of that job was never done -- invoking a closure needs to be considered a unique-immutable borrow (a handy concept brought into being, at least internally, by #6801).

The goal is to prevent a program like this from compiling:

use std::hashmap::HashMap;

type Fn<'a> = 'a ||;

fn call1(c: |Fn|) {
    c(|| {
        c(|| ());
    });
}

pub fn main() {
    println!("Hello, world!");
    let mut map = HashMap::new();
    let mut c = 0;
    call1(|f| {
            error!("Inserting");
            map.insert(22, c);
            c += 1;
            error!("Finding");
            let x = map.find(&22).unwrap();
            let y = *x;
            assert_eq!(*x, y);
            f();
            error!("Found {}", *x);
            assert_eq!(*x, y);
});
}

Part of #2202.

Nominating for 1.0 (backwards compat).

[alexcrichton]

Should #7836 be closed as a dupe of this?

[nikomatsakis]

Ah, I missed that issue, thanks @alexcrichton

[glaebhoerl]

Would(n't) this fall out automatically with the "closures are trait objects" approach?

[pnkfelix]

Inherits designation from #7836: P-backcompat-lang, 1.0 blocker.

[nikomatsakis]

@glaebhoerl yes.

[huonw]

Something similar (an updated version of the case of the recurring closure):

// FIXME #11211
type Closure<'a> = 'a |&R|;

struct R<'a, 'b> {
    c: &'a mut Closure<'b>
}

fn innocent_looking_victim() {
    let mut vec = ~[1, 2, 3];
    conspirator(|f| {
        if vec.len() < 100 {
            vec.push(4);
            for _ in vec.iter() {
                (*f.c)(f)
            }
        }
    })
}

fn conspirator(mut f: |&R|) {
    let r = R {c: &mut f};
    f(&r)
}

fn main() {
    innocent_looking_victim()
}

This compiles with any combination of mut's for the c: & .. |& .. R| field.