Variables not always moved into async move block

[Ploppz]

Playground:

use std::cell::UnsafeCell;
use std::sync::{Arc, Mutex};

#[tokio::main]
async fn main() {
    let arena = 0;
    let mut track = Vec::new();
    async move { track.push(&arena) }.await;
}

rustc v1.47.0 stable

Error:

error[E0597]: `arena` does not live long enough
 --> src/main.rs:8:29
  |
7 |     let mut track = Vec::new();
  |         --------- lifetime `'1` appears in the type of `track`
8 |     async move { track.push(&arena) }.await;
  |                  -----------^^^^^^- - `arena` dropped here while still borrowed
  |                  |          |
  |                  |          borrowed value does not live long enough
  |                  argument requires that `arena` is borrowed for `'1`

error: aborting due to previous error; 2 warnings emitted

Which is because track is captured by reference and not by value, while arena is captured by value.

By submitting this issue, I assume that the intended semantics for move is:

move value(s) into the closure/block, even if the closure/block only seems to need to store reference(s)

which would make this a bug.

[jyn514]

Slightly minimized (playground):

async fn f() {
    let arena = 0;
    async move { &arena }.await;
}

error[E0515]: cannot return reference to local data `arena`
 --> src/lib.rs:5:18
  |
5 |     async move { &arena }.await;
  |                  ^^^^^^ returns a reference to data owned by the current function

error: aborting due to previous error

[jyn514]

Actually that's not quite right because it returns a reference. I think https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=51d3946643a798e189b33af33ec4e88f is closer.

[jyn514]

I think the issue is that this is a self-referential struct: the future stores both track and arena, so by putting a pointer to arena into track you end up with a future that points to itself, which isn't allowed. by-move and by-value aren't related.

[jyn514]

Yeah, if you remove move it works fine: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=016951a394128bd17a2b46dd84b435c3

[Ploppz]

That works because if you drop(track) or drop(arena) you actually only drop the reference I think?

I think this fix to my initial playground, adding let mut track = track; to coerce the compiler to capture by value, shows that the problem is that it actually captures by reference by default
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4ddfa084cc64cbfe3465e0228ce2d7b1

Edit:
And shows that it's not a problem that the future is self referential.
And yes it works if you remove the move, because it captures both variables by reference. The problem when move is there is precisely, in my understanding, that it captures arena by value and track by reference so that arena is dropped before track.

[jyn514]

That works because if you drop(track) or drop(arena) you actually only drop the reference I think?

It breaks without drop, too, that was just to make it more clear. I guess it didn't work 😆

I think this fix to my initial playground, adding let mut track = track; to coerce the compiler to capture by value, shows that the problem is that it actually captures by reference by default

That's because you're pushing to a new, non-captured variable now - it's no longer stored in the future. If you capture after the push it still breaks: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4d3a959ef9a3cae41bcde778822bedda

[nikomatsakis]

The errors are correct but confusing. In the move case, the arena variable is owned by the closure (well, generator), so you can't push it onto the vector that is owned by the creator stack frame, since the lifetime of the closure is not related to the lifetime of that vector. But in the non-move case, the arena variable remains owned by the other stack frame, so you can.

[nikomatsakis]

Er, I explained that slightly wrong. For the move case both arena and track are owned by the generator, but that still requires it to be self-referential (i.e., to put a reference to one field into the vector).

[tmandry]

This also isn't specific to async, we can see the same behavior with regular closures:

fn main() {
    let arena = 0;
    let mut track = Vec::new();
    (move || {
        //let mut track = track;
        track.push(&arena)
    })();
}

in this case uncommenting the commented line, or removing move, is enough to let the example compile. The error message in this case:

error[E0521]: borrowed data escapes outside of closure
 --> src/main.rs:9:9
  |
6 |     let mut track = Vec::new();
  |         --------- `track` declared here, outside of the closure body
...
9 |         track.push(&arena)
  |         ^^^^^^^^^^^^^^^^^^

is different from the error message in the async case:

error[E0597]: `arena` does not live long enough
  --> src/main.rs:10:20
   |
7  |     let mut track = Vec::new();
   |         --------- lifetime `'1` appears in the type of `track`
...
10 |         track.push(&arena)
   |         -----------^^^^^^-
   |         |          |
   |         |          borrowed value does not live long enough
   |         argument requires that `arena` is borrowed for `'1`
11 |     }
   |     - `arena` dropped here while still borrowed

...and honestly, I think both of them could use some improvement. The async one actually seems a little better to me personally.

[tmandry]

As discussed in the wg-async-foundations meeting, we could support this in the async case at least, since async generators are allowed to be self-borrowing. But since we handle their captures the same as we handle closures, we don't support it today.