"cannot move out of captured outer variable in an `FnMut` closure" should mention the outer variable

[Manishearth]

use std::thread;

fn main() {
    let things = vec![1,2,3,4];
    let mut buf = vec![];
    let handle_thread: Vec<_> = things.iter().map(|&d| {
        thread::spawn(move || {
            do_thing(&mut buf);
        })
    }).collect();
}

fn do_thing(x: &mut [u8]) {}

(https://gist.github.com/772bde36b6cddebcd46a)

gives

<anon>:11:17: 13:4 error: cannot move out of captured outer variable in an `FnMut` closure [E0507]
<anon>:11       thread::spawn(move || {
<anon>:12           do_thing(&mut buf);
<anon>:13       })
error: aborting due to previous error

Except that it's totally confusing as to which outer variable is being talked about. In this case it's obvious since there's a single capture, but this won't always be the case.

The error should at least mention the name of the captured variable, and preferably point out where the variable was captured and how to fix it.

[sheganinans]

I've ran into this error, until this issue is closed maybe it would be good to have an example of a fix here. Thanks!

[Manishearth]

The fix is to figure out which captured variable is being moved and not move it. In this case, the variable buf is owned by the outer closure and needs to be kept around since the outer closure will get called multiple times. However, the inner move closure is moving it, so it gets used up after the first call. In this specific case to fix this error you would do something like let buf = &mut buf right before spawning the thread. This causes a lifetime error because the program example is an untenable one, but it's more or less what a general fix would look like.

[sheganinans]

Perfect, thanks!

On Tue, Apr 19, 2016 at 8:53 AM, Manish Goregaokar <notifications@github.com

wrote:

The fix is to figure out which captured variable is being moved and not
move it. In this case, the variable buf is owned by the outer closure and
needs to be kept around since the outer closure will get called multiple
times. However, the inner move closure is moving it, so it gets used up
after the first call. In this specific case to fix this error you would do
something like let buf = &mut buf right before spawning the thread. This
causes a lifetime error because the program example is an untenable one,
but it's more or less what a general fix would look like.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#31752 (comment)

[kornelski]

I've ran into this too.

    let mut tmp = 1;
    let c = &mut tmp;

    vec![0;10].iter().flat_map(|&a| {
        (0..10).map(move |b|{
            a + b + *c
        })
    });

cannot move out of captured outer variable in an FnMut closure

The error does not say that the problematic variable is c.

In real code, with multiple variables used and type inference hiding the details, it is really hard to figure out what this error is about.

[jonhoo]

Yet another example of this (simplified from an actual use-case I ran into):

fn main() {
    use std::thread;
    use std::sync::mpsc;

    let (tx, rx) = mpsc::channel();
    let n = 10;
    let foos: Vec<_> = (0..n)
        .into_iter()
        .map(|i| thread::spawn(move || -> bool { rx.recv().unwrap() }))
        .collect();
}

[jonhoo]

The compiler is a little better at this now that it highlights which variable is the problem, but I think we could still do better. Consider

fn foo(mut f: Box<FnMut()>) {
    f();
}

fn main() {
    let x = vec![];
    x.push(true);
    let y = true;
    foo(Box::new(move || y = false) as Box<_>);
}

error: cannot borrow immutable local variable `x` as mutable
 --> x.rs:7:5
  |
6 |     let x = vec![];
  |         - use `mut x` here to make mutable
7 |     x.push(true);
  |     ^ cannot borrow mutably

error: cannot assign to captured outer variable in an `FnMut` closure
 --> x.rs:9:26
  |
9 |     foo(Box::new(move || y = false) as Box<_>);
  |                          ^^^^^^^^^

For x, the compiler helpfully tells the user that they can make x mut, and everything will be fine. For y, the solution is the same (and, arguably, the problem is the same), but the compiler makes no such recommendation.