Two MUTABLE borrows to local var, by pushing closures into RefCell'd Vec through a trait.

[cristicbz]

Looks like a bug in the borrow checker:

use std::cell::RefCell;

fn main() {
    let c = Caller::new();
    let mut y = 1;  // NOT in RefCell.
    c.pusher().push(|| { y = y * 2u; });
    c.pusher().push(|| { y = y * 3u; });  // Second mutable borrow of y?!
    c.call();
    println!("{}", y); // Prints 6.
}

// Collects multiple closures then call all of them.
struct Caller<'c> {
    funs: RefCell<Vec<||:'c -> ()>>,
} impl<'c> Caller<'c> {
    fn new() -> Caller<'c> {
        Caller { funs: RefCell::new(Vec::new()) }
    }

    fn pusher(&'c self) -> Pusher<'c> {
        Pusher { caller: self }
    }

    fn call(&self) {
        let ref mut funs = self.funs.borrow_mut();
        loop {
            match funs.pop() {
                Some(f) => f(),
                _ => break,
            }
        }
    }
}

// Pushes closures into a caller.
trait Push<'c> {
    fn push<'f: 'c>(self, push: ||:'f -> ());
}

struct Pusher<'c> {
    caller: &'c Caller<'c>
}
// /*
impl<'c> Push<'c> for Pusher<'c> {
    fn push<'f: 'c>(self, fun: ||:'f -> ()) {
        self.caller.funs.borrow_mut().push(fun)
    }
}
// Using the following impl (without trait) makes compilation fail correctly: */
/*
impl<'c> Pusher<'c> {
    fn push<'f: 'c>(self, fun: ||:'f -> ()) {
        self.caller.funs.borrow_mut().push(fun)
    }
}
*/

Playpen

This compiles and runs fine. It also compiles when using unboxed closures instead (using type param F: FnOnce<(), ()>+'c and F members). Using the non-trait impl, however, causes compilation to fail correctly:

<anon>:7:21: 7:39 error: cannot borrow `y` as mutable more than once at a time
<anon>:7     c.pusher().push(|| { y = y * 3u; });  // Second mutable borrow of y?!
                             ^~~~~~~~~~~~~~~~~~
<anon>:7:30: 7:31 note: borrow occurs due to use of `y` in closure
<anon>:7     c.pusher().push(|| { y = y * 3u; });  // Second mutable borrow of y?!
                                      ^
<anon>:6:21: 6:39 note: previous borrow of `y` occurs here due to use in closure; the mutable borrow prevents subsequent moves, borrows, or modification of `y` until the borrow ends
<anon>:6     c.pusher().push(|| { y = y * 2u; });
                             ^~~~~~~~~~~~~~~~~~
<anon>:10:2: 10:2 note: previous borrow ends here
<anon>:3 fn main() {
...
<anon>:10 }
          ^
<anon>:9:20: 9:21 error: cannot borrow `y` as immutable because it is also borrowed as mutable
<anon>:9     println!("{}", y); // Prints 6.
                            ^
note: in expansion of format_args!
<std macros>:2:23: 2:77 note: expansion site
<std macros>:1:1: 3:2 note: in expansion of println!
<anon>:9:5: 9:23 note: expansion site
<anon>:6:21: 6:39 note: previous borrow of `y` occurs here due to use in closure; the mutable borrow prevents subsequent moves, borrows, or modification of `y` until the borrow ends
<anon>:6     c.pusher().push(|| { y = y * 2u; });
                             ^~~~~~~~~~~~~~~~~~
<anon>:10:2: 10:2 note: previous borrow ends here
<anon>:3 fn main() {
...
<anon>:10 }
          ^
<anon>:9:20: 9:21 error: cannot borrow `y` as immutable because it is also borrowed as mutable
<anon>:9     println!("{}", y); // Prints 6.
                            ^
note: in expansion of format_args!
<std macros>:2:23: 2:77 note: expansion site
<std macros>:1:1: 3:2 note: in expansion of println!
<anon>:9:5: 9:23 note: expansion site
<anon>:7:21: 7:39 note: previous borrow of `y` occurs here due to use in closure; the mutable borrow prevents subsequent moves, borrows, or modification of `y` until the borrow ends
<anon>:7     c.pusher().push(|| { y = y * 3u; });  // Second mutable borrow of y?!
                             ^~~~~~~~~~~~~~~~~~
<anon>:10:2: 10:2 note: previous borrow ends here
<anon>:3 fn main() {
...
<anon>:10 }
          ^
error: aborting due to 3 previous errors
playpen: application terminated with error code 101
Program ended.

[bkoropoff]

Reduced a bit further:

use std::cell::RefCell;

fn main() {
    let c = RefCell::new(vec![]);
    let mut y = 1u;
    c.push(|| y = 0);
    c.push(|| y = 0);
    // confliciting borrow detected when not going through trait
    // c.borrow_mut().push(|| y = 0);
    // c.borrow_mut().push(|| y = 0);
}

trait Push<'c> {
    fn push<'f: 'c>(&self, push: ||:'f -> ());
}

impl<'c> Push<'c> for RefCell<Vec<||:'c>> {
    fn push<'f: 'c>(&self, fun: ||:'f -> ()) {
        self.borrow_mut().push(fun)
    }
}

This is a regression from 0.12. cc @nikomatsakis

[bkoropoff]

git bisect shows this came in with #18121

[bkoropoff]

I tried #18694 on a hunch, and it fixes this issue.

[pnkfelix]

P-backcompat-lang, 1.0.

[nikomatsakis]

This is not entirely fixed by #18694, there is another guise. Here is a revised test:

// Copyright 2014 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

use std::cell::RefCell;

fn main() {
    let c = RefCell::new(vec![]);
    let mut y = 1u;

    c.push(|| y = 0);
    c.push(|| y = 0);
    // confliciting borrow detected when not going through trait
    // c.borrow_mut().push(|| y = 0);
    // c.borrow_mut().push(|| y = 0);
}

fn ufcs() {
    let c = RefCell::new(vec![]);
    let mut y = 1u;

    Push::push(&c, || y = 0);
    Push::push(&c, || y = 0);
}

trait Push<'c> {
    fn push<'f: 'c>(&self, push: ||:'f -> ());
}

impl<'c> Push<'c> for RefCell<Vec<||:'c>> {
    fn push<'f: 'c>(&self, fun: ||:'f -> ()) {
        self.borrow_mut().push(fun)
    }
}

the second set of calls using UFCS form passes.

[nikomatsakis]

(I suspect though this second form is a dup of #18899)

[nikomatsakis]

Ah, no, I think what is happening is that the 'c in the trait is actually inferred to be bivariant, since it does not appear in the interface itself. My variance branch would fix it by making bivariance illegal, but I feel like that's papering over the problem -- I want to get a better understanding of what's going wrong here.

[nikomatsakis]

(I presume the problem is that the variance inference must take the 'f:'c relationship into account, which it currently does not)