Avoid GenFuture shim when compiling async constructs

[Swatinem]

Previously, async constructs would be lowered to "normal" generators, with an additional from_generator / GenFuture shim in between to convert from Generator to Future.

The compiler will now special-case these generators internally so that async constructs will directly implement Future without the need to go through the from_generator / GenFuture shim.

The primary motivation for this change was hiding this implementation detail in stack traces and debuginfo, but it can in theory also help the optimizer as there is less abstractions to see through.

---

Given this demo code:

pub async fn a(arg: u32) -> Backtrace {
    let bt = b().await;
    let _arg = arg;
    bt
}

pub async fn b() -> Backtrace {
    Backtrace::force_capture()
}

I would get the following with the latest stable compiler (on Windows):

   4: async_codegen::b::async_fn$0
             at .\src\lib.rs:10
   5: core::future::from_generator::impl$1::poll<enum2$<async_codegen::b::async_fn_env$0> >
             at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\future\mod.rs:91
   6: async_codegen::a::async_fn$0
             at .\src\lib.rs:4
   7: core::future::from_generator::impl$1::poll<enum2$<async_codegen::a::async_fn_env$0> >
             at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\future\mod.rs:91

whereas now I get a much cleaner stack trace:

   3: async_codegen::b::async_fn$0
             at .\src\lib.rs:10
   4: async_codegen::a::async_fn$0
             at .\src\lib.rs:4

[rustbot]

r? @oli-obk

(rustbot has picked a reviewer for you, use r? to override)

[Swatinem]

@cjgillot thanks for the review.

I implemented the feedback, defining separate structures / functions for the future case in trait selection.

I also fixed a couple of tests and blessed some test assertions that are clear improvements:

• better spans for async blocks, (now covers the whole async {} instead of just the {} part)
• tests that assumed from_generator wrapping (including moves)
• removed a couple of error[E0391]: cycle detected when computing type of … errors, though I’m not entirely confident about that one.

Maybe I missed a couple of things though.

---

The main regression that now remains is, and that you pointed out on zulip:

error[E0700]: hidden type for `impl Future<Output = _>` captures lifetime that does not appear in bounds

This may be related to another change in diagnostics:

-	   = note: required because it captures the following types: `ResumeTy`, `(NotSend,)`, `impl Future<Output = ()>`, `()`
+	   = note: required because it captures the following types: `&mut Context<'_>`, `(NotSend,)`, `impl Future<Output = ()>`, `()`

As this now avoids the whole ResumeTy in favor of using the Context directly, that might be a reason for both these changes.

ResumeTy as it exists today in the shim I believe has the purpose to hide all these lifetimes behind some raw pointers and unsafe code to then conjure up the lifetimes again out of thin air in get_context:

rust/library/core/src/future/mod.rs

Line 106 in 084ad59

pub unsafe fn get_context<'a, 'b>(cx: ResumeTy) -> &'a mut Context<'b> {

As I was asking on zulip: Do we need this at all, or can we just avoid checking the resume type at all? I’m also wondering why the generator is "capturing" that type at all? It shouldn’t be?

---

As a separate question: Should I remove the whole from_generator glue code from the std library right away, or rather wait one cycle in case some external code might rely on that directly?

[oli-obk]

r? @cjgillot

@bors try @rust-timer queue

[bors]

⌛ Trying commit 69930d3 with merge eaf9cebf4a95bc065d5aee8056b24fc910ac20e0...

[bors]

💔 Test failed - checks-actions

[Swatinem]

I switched back to using ResumeTy and get_context which solves most of the new E0700 issues.

I’m down to 12 failures:

• 6 are adding a new note that I believe I can figure out how to get rid of
• 2 now falsely assume async blocks are const. well as they are "just data", they are, but there is still that feature flag for it I should respect ;-)
• src/test\ui\generic-associated-types\bugs\issue-100013.rs suggests adding a async move, though not sure where that is coming from.

That leaves:

• src/test\ui\regions\issue-72051-member-region-hang.rs and src/test\ui\self\self_lifetime-async.rs are complaining about E0700 captured lifetimes.
• src/test\ui\impl-trait\in-trait\default-body-with-rpit.rs now has a E0720 cannot resolve opaque type.

I believe for these I might need to hook up the return type in a different way somehow, not yet sure how to do that.

[bors]

☔ The latest upstream changes (presumably #104219) made this pull request unmergeable. Please resolve the merge conflicts.

[bjorn3]

As of this PR cg_clif's CI is failing with

thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `&mut std::task::Context<'_>`,
 right: `std::future::ResumeTy`: Can't write value with incompatible type Ref(ReErased, std::task::Context<'_>, Mut) to place with type Adt(std::future::ResumeTy, [])

It seems that an &mut Context<'_> is passed to poll function expecting ResumeTy. Both types are currently abi compatible by accident, but -Zrandomize-layout will break this in the future once it starts randomly adding padding to types.

[bjorn3]

And after a patch to make it ignore this particular mismatch I get:

 thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
  left: `std::ops::GeneratorState<(), ()>`,
 right: `std::task::Poll<()>`: Can't write value with incompatible type Adt(std::ops::GeneratorState, [(), ()]) to place with type Adt(std::task::Poll, [()])

Poking a bit around confirms that <[async fn body@example/std_example.rs:20:19: 20:21] as std::future::Future>::poll does indeed accept ResumeTy and return std::ops::GeneratorState<(), ()> in violation of the Future::poll signature.

[src/abi/mod.rs:402] &instance = Some(Instance {
    def: Item(WithOptConstParam { did: DefId(0:20 ~ std_example[7fb1]::future::{closure#0}), const_param_did: None }),
    substs: [std::future::ResumeTy, (), (), {}, ()],
})
[src/abi/mod.rs:402] &fn_abi = FnAbi {
    args: [
        ArgAbi {
            layout: TyAndLayout {
                ty: std::pin::Pin<&mut [async fn body@example/std_example.rs:20:19: 20:21]>,
                layout: ...,
            },
            mode: Direct(...),
        },
        ArgAbi {
            layout: TyAndLayout {
                ty: std::future::ResumeTy,
                layout: ...,
            },
            mode: Direct(...),
        },
    ],
    ret: ArgAbi {
        layout: TyAndLayout {
            ty: std::ops::GeneratorState<(), ()>,
            layout: ...,
        },
        mode: Direct(...),
    },
    c_variadic: false,
    fixed_count: 2,
    conv: Rust,
    can_unwind: false,
}

A minimal reproducing example is:

#![feature(pin_macro)]

use std::pin::{pin, Pin};
use std::future::Future;
use std::ptr::null;
use std::task::{Context, Waker, RawWaker, RawWakerVTable};

fn main() {
    let waker = unsafe {
        Waker::from_raw(RawWaker::new(null(), &RawWakerVTable::new(|_| todo!(), |_| todo!(), |_| todo!(), |_| todo!())))
    };
    let mut cx = Context::from_waker(&waker);
    call_future(pin!(future()), &mut cx);
}

fn call_future(fut: Pin<&mut impl Future<Output = ()>>, cx: &mut Context) {
    fut.poll(cx);
}

async fn future() {}

[oli-obk]

This is being fixed in #105082 (comment)

[bjorn3]

Thanks for the pointer!

[Swatinem]

#105082 will indeed fix the mismatch of GeneratorState return type.

I will have a fix for #104828 up shortly that will tackle the ResumeTy mismatch.