async/await borrows more around await points than necessary

[sdroege]

    let foo = Mutex::new("123");

    let foo: Box<dyn futures::future::Future<Output = ()> + Send> = Box::new(async move {
        // In a separate block works
        // {
        let bar = foo.lock().unwrap();
        drop(bar);
        // }
        futures::future::lazy(|_| ()).await;
    });

Fails with

error[E0277]: `std::sync::MutexGuard<'_, &str>` cannot be sent between threads safely

When putting the lock into a separate block it works fine, when not awaiting or locking after the last await point it also works fine.

It seems that dropped values at await points are still considered in scope and borrowed.

[pnkfelix]

This ... might be a deliberate choice?

In particular, there has been some discussion circling around whether the behavior in cases like this should be based on lexical scopes (as I believe is currently the case) or a liveness analysis (which what I think @sdroege is implicitly asking for here)?

But I'm not an expert in what is the general expectation when it come to async-await semantics. cc @cramertj and @withoutboats

[withoutboats]

Maybe I'm confused, but I don't think this is a deliberate choice and I think its connected #52924.

What we've decided is that we don't rearrange destructors in any surprising way, but once something has been dropped we shouldn't need to hold it in the state any longer. I don't think fixing this is a blocker (since it should be strictly backwards compatible for these generators to gain a Send impl), but I think this is a bug.

[cramertj]

cc @tmandry

[sdroege]

I don't think fixing this is a blocker [...] but I think this is a bug.

I agree, and it's also easy enough to workaround and you'll notice at compile time. It's mostly an inconvenience.

[tmandry]

Typecheck has its own "view" of what locals might get incorporated into the generator, and that would be what's generating this error.

That's separate from the layout code (except that the layout set of saved locals must be a subset of the typecheck set). So I would say this isn't really part of #52924.

EDIT: The typeck set is the one in GeneratorWitness.

[nikomatsakis]

This is I think a dup of #57017

[nikomatsakis]

Based on that, I'm going to mark as deferred -- probably we should move the example into #57017 and close this issue though

[sdroege]

Based on that, I'm going to mark as deferred -- probably we should move the example into #57017 and close this issue though

Added it in a comment there. Thanks!

[Nemo157]

#57478 is another more specific dup.