Async drop codegen

[azhogin]

Async drop implementation using templated coroutine for async drop glue generation.
Implementation details:
https://github.com/azhogin/posts/blob/main/async-drop-impl.md

Implementation is splitted into 12 parts for review purposes:
1). New fields in Drop terminator (drop & async_fut). Processing in codegen/miri must validate that those fields are empty (in full version async Drop terminator will be expanded at StateTransform pass or reverted to sync version). Changes in terminator visiting to consider possible new successor (drop field).
#129734
2). ResumedAfterDrop messages for panic when coroutine is resumed after it is started to be async drop'ed.
#129736
3). Lang item for generated coroutine for async function async_drop_in_place. async fn async_drop_in_place<T>()::{{closure0}}.
#129737
4). is_async_drop_raw and small needs_async_drop fixes and previous async drop glue implementation cleanup.
#129739
5). Instances and resolving. AsyncDropGlueCtorShim for async_drop_in_place() function returning drop coroutine. AsyncDropGlue for async drop coroutine. FutureDropPoll for async drop of coroutine.
#129740
6). Templated coroutine support. async fn async_drop_in_place<T>()::{{closure0}} (async drop coroutine) has completely different layout for different dropped types T, so it cannot be represented by generic coroutine, we need to implement templated coroutine with code generation after all GenericArgs substituted.
#129741
7). Library changes. async fn async_drop_in_place<T>() declaration etc.
#129742
8). Scopes processing for generate async drop preparations. Async drop is a hidden Yield, so potentially async drops require the same dropline preparation as for Yield terminators.
#129744
9). Drop elaboration.
#129745
10). Processing in StateTransform. Async drops are expanded into yield-point. Generation of async drop of coroutine itself added.
#129746
11). Shim generation. Shims for AsyncDropGlueCtorShim, AsyncDropGlue and FutureDropPoll.
#129747
12). Tests.

#[lang = "async_drop"]
pub trait AsyncDrop {
    #[allow(async_fn_in_trait)]
    async fn drop(self: Pin<&mut Self>);
}

impl Drop for Foo {
    fn drop(&mut self) {
        println!("Foo::drop({})", self.my_resource_handle);
    }
}

impl AsyncDrop for Foo {
    async fn drop(self: Pin<&mut Self>) {
        println!("Foo::async drop({})", self.my_resource_handle);
    }
}

First async drop glue implementation re-worked to use the same drop elaboration code as for sync drop.
async_drop_in_place changed to be async fn. So both async_drop_in_place ctor and produced coroutine have their lang items (AsyncDropInPlace/AsyncDropInPlacePoll) and shim instances (AsyncDropGlueCtorShim/AsyncDropGlue).

pub async unsafe fn async_drop_in_place<T: ?Sized>(_to_drop: *mut T) {
}

AsyncDropGlue shim generation uses elaborate_drops::elaborate_drop to produce drop ladder (in the similar way as for sync drop glue) and then coroutine::StateTransform to convert function into coroutine poll.

AsyncDropGlue coroutine's layout can't be calculated for generic T, it requires known final dropee type to be generated (in StateTransform). So, templated coroutine was introduced here (templated_coroutine_layout(...) etc).

Such approach overrides the first implementation using mixing language-level futures in #121801.

[rustbot]

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @celinval, @vakaras

This PR changes Stable MIR

cc @oli-obk, @celinval, @ouz-a

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[slanterns]

How does this relate to #121801?

[azhogin]

How does this relate to #121801?

This is a proof-of-concept of async drop implementation with only final drop function (no glue for child objects drop).
Async drop glue generation implemented in #121801. We will intergate this two PRs.

[RalfJung]

There's something strange going on that's not explained in the comments in syntax.rs -- why are these things entirely ignored by the interpreter and codegen?

[azhogin]

Yes, both drop and async_fut fields are only used in compiler/rustc_mir_transform/src/coroutine.rs, StateTransform pass. In expand_async_drops async drops are expanded into one or two yield points with poll ready/pending switch.

Drop terminator comments updated.

[RalfJung]

In that case codegen and the interpreter should bug! when those fields are present.

Though it seems to me it would probably be better to make this a different terminator. They have very different operational behavior, after all.

[RalfJung]

What does it mean for the coroutine to be "dropped at this suspend point"? I don't understand under which conditions the code will jump to the drop block.

Does it really make sense to make the existing Drop terminator do both regular drop and async drop? Either way, the doc comment for the terminator needs to be a self-contained explanation of what exactly happens when the terminator is executed.

[azhogin]

Async drop in StateTransform pass will be expanded into yield point for poll-loop of internal drop coroutine. So, we need the same drop target block prepared for async Drop, as for Yield terminator. It means - "where the main coroutine should go, if it is dropped at this yield point (drop pool-loop)".
StateTransform pass generates "coroutine_resume" function for poll and "coroutine_drop_async" for drop of coroutine itself. Both functions are switches: for resume function state target blocks are taken from target field of Yield (or async Drop) and for drop function state target blocks are taken from drop field of Yield (or async Drop).

Yes, I think keeping Drop terminator for both sync/async is good atm because async Drop is optionally expanded if conditions are met. For sync context (just inside normal function) and for unwind - we can't use AsyncDrop atm, so sync drop must be as a fallback.

Drop terminator comments updated.

[zetanumbers]

I would say this is a bit overblown and a single poll would have been enough.

[azhogin]

It shows an example of correct block_on function for async drop coroutine. I don't see a reason to optimize test here.

[zetanumbers]

To clarify: if I understood everyone correctly this PR implements async drop with some features, which are considered to be undesirable by a number of Async WG members (regular drop after async drop was suspended, etc.) This is fine as long as we would be capable of disabling those (by restricting synchronous drop for such coroutines).

[zetanumbers]

Probably should match on TerminatorKind::Drop { async_fut: Some(_), drop: Some(_), .. } in "shouldn't exist at codegen" branch, and put None in these fields in old drop case.

[bjorn3]

Can you make this change to rustc_codegen_cranelift too at

rust/compiler/rustc_codegen_cranelift/src/abi/mod.rs

Line 600 in f092f73

if let ty::InstanceDef::DropGlue(_, None) | ty::InstanceDef::AsyncDropGlueCtorShim(_, None) =

and

rust/compiler/rustc_codegen_cranelift/src/abi/mod.rs

Line 415 in f092f73

InstanceDef::DropGlue(_, None) | ty::InstanceDef::AsyncDropGlueCtorShim(_, None) => {

?

[azhogin]

It is splitted into small PRs. @rustbot ready

[bors]

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

[davidtwco]

r? @nikomatsakis is going to look into this