Async drop codegen #123948

azhogin · 2024-04-15T00:10:33Z

Proof-of-concept of async drop implementation with only final drop function (no glue for child objects drop).
Implementation details:
https://github.com/azhogin/posts/blob/main/async-drop-impl.md

#[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 · 2024-04-15T00:10:41Z

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 · 2024-04-15T00:10:42Z

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 · 2024-04-15T04:30:57Z

How does this relate to #121801?

azhogin · 2024-04-15T05:35:12Z

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.

compiler/rustc_middle/src/ty/instance.rs

RalfJung · 2024-04-16T17:37:01Z

compiler/rustc_const_eval/src/interpret/terminator.rs

@@ -170,7 +170,7 @@ impl<'mir, 'tcx: 'mir, M: Machine<'mir, 'tcx>> InterpCx<'mir, 'tcx, M> {
                }
            }

-            Drop { place, target, unwind, replace: _ } => {
+            Drop { place, target, unwind, replace: _, drop: _, async_fut: _ } => {


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?

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.

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 · 2024-04-16T17:38:38Z

compiler/rustc_middle/src/mir/syntax.rs

+        target: BasicBlock,
+        unwind: UnwindAction,
+        replace: bool,
+        /// Cleanup to be done if the coroutine is dropped at this suspend point (for async drop).


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.

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.

…-obk Add simple async drop glue generation This is a prototype of the async drop glue generation for some simple types. Async drop glue is intended to behave very similar to the regular drop glue except for being asynchronous. Currently it does not execute synchronous drops but only calls user implementations of `AsyncDrop::async_drop` associative function and awaits the returned future. It is not complete as it only recurses into arrays, slices, tuples, and structs and does not have same sensible restrictions as the old `Drop` trait implementation like having the same bounds as the type definition, while code assumes their existence (requires a future work). This current design uses a workaround as it does not create any custom async destructor state machine types for ADTs, but instead uses types defined in the std library called future combinators (deferred_async_drop, chain, ready_unit). Also I recommend reading my [explainer](https://zetanumbers.github.io/book/async-drop-design.html). This is a part of the [MCP: Low level components for async drop](rust-lang/compiler-team#727) work. Feature completeness: - [x] `AsyncDrop` trait - [ ] `async_drop_in_place_raw`/async drop glue generation support for - [x] Trivially destructible types (integers, bools, floats, string slices, pointers, references, etc.) - [x] Arrays and slices (array pointer is unsized into slice pointer) - [x] ADTs (enums, structs, unions) - [x] tuple-like types (tuples, closures) - [ ] Dynamic types (`dyn Trait`, see explainer's [proposed design](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#async-drop-glue-for-dyn-trait)) - [ ] coroutines (rust-lang#123948) - [x] Async drop glue includes sync drop glue code - [x] Cleanup branch generation for `async_drop_in_place_raw` - [ ] Union rejects non-trivially async destructible fields - [ ] `AsyncDrop` implementation requires same bounds as type definition - [ ] Skip trivially destructible fields (optimization) - [ ] New [`TyKind::AdtAsyncDestructor`](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#adt-async-destructor-types) and get rid of combinators - [ ] [Synchronously undroppable types](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#exclusively-async-drop) - [ ] Automatic async drop at the end of the scope in async context

zetanumbers · 2024-04-19T14:21:06Z

tests/ui/async-await/async-drop/async-drop-future-from-future.rs

+fn block_on<F>(fut_unpin: F) -> F::Output
+where
+    F: Future,
+{
+    let mut fut_pin = pin!(ManuallyDrop::new(fut_unpin));
+    let mut fut: Pin<&mut F> = unsafe {
+		Pin::map_unchecked_mut(fut_pin.as_mut(), |x| &mut **x)
+	};
+    let (waker, rx) = simple_waker();
+    let mut context = Context::from_waker(&waker);
+    let rv = loop {
+        match fut.as_mut().poll(&mut context) {
+            Poll::Ready(out) => break out,
+            // expect wake in polls
+            Poll::Pending => rx.try_recv().unwrap(),
+        }
+    };
+    loop {
+        match future_drop_poll(fut.as_mut(), &mut context) {
+            Poll::Ready(()) => break,
+            // expect wake in polls
+            Poll::Pending => rx.try_recv().unwrap(),
+        }
+    }
+    rv
+}


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

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

zetanumbers · 2024-04-19T14:59:05Z

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 · 2024-04-22T11:52:48Z

compiler/rustc_codegen_cranelift/src/base.rs

+                replace: _,
+                drop: _,
+                async_fut: _,
+            } => {


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.

Add simple async drop glue generation This is a prototype of the async drop glue generation for some simple types. Async drop glue is intended to behave very similar to the regular drop glue except for being asynchronous. Currently it does not execute synchronous drops but only calls user implementations of `AsyncDrop::async_drop` associative function and awaits the returned future. It is not complete as it only recurses into arrays, slices, tuples, and structs and does not have same sensible restrictions as the old `Drop` trait implementation like having the same bounds as the type definition, while code assumes their existence (requires a future work). This current design uses a workaround as it does not create any custom async destructor state machine types for ADTs, but instead uses types defined in the std library called future combinators (deferred_async_drop, chain, ready_unit). Also I recommend reading my [explainer](https://zetanumbers.github.io/book/async-drop-design.html). This is a part of the [MCP: Low level components for async drop](rust-lang/compiler-team#727) work. Feature completeness: - [x] `AsyncDrop` trait - [ ] `async_drop_in_place_raw`/async drop glue generation support for - [x] Trivially destructible types (integers, bools, floats, string slices, pointers, references, etc.) - [x] Arrays and slices (array pointer is unsized into slice pointer) - [x] ADTs (enums, structs, unions) - [x] tuple-like types (tuples, closures) - [ ] Dynamic types (`dyn Trait`, see explainer's [proposed design](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#async-drop-glue-for-dyn-trait)) - [ ] coroutines (rust-lang#123948) - [x] Async drop glue includes sync drop glue code - [x] Cleanup branch generation for `async_drop_in_place_raw` - [ ] Union rejects non-trivially async destructible fields - [ ] `AsyncDrop` implementation requires same bounds as type definition - [ ] Skip trivially destructible fields (optimization) - [ ] New [`TyKind::AdtAsyncDestructor`](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#adt-async-destructor-types) and get rid of combinators - [ ] [Synchronously undroppable types](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#exclusively-async-drop) - [ ] Automatic async drop at the end of the scope in async context

Add simple async drop glue generation This is a prototype of the async drop glue generation for some simple types. Async drop glue is intended to behave very similar to the regular drop glue except for being asynchronous. Currently it does not execute synchronous drops but only calls user implementations of `AsyncDrop::async_drop` associative function and awaits the returned future. It is not complete as it only recurses into arrays, slices, tuples, and structs and does not have same sensible restrictions as the old `Drop` trait implementation like having the same bounds as the type definition, while code assumes their existence (requires a future work). This current design uses a workaround as it does not create any custom async destructor state machine types for ADTs, but instead uses types defined in the std library called future combinators (deferred_async_drop, chain, ready_unit). Also I recommend reading my [explainer](https://zetanumbers.github.io/book/async-drop-design.html). This is a part of the [MCP: Low level components for async drop](rust-lang/compiler-team#727) work. Feature completeness: - [x] `AsyncDrop` trait - [ ] `async_drop_in_place_raw`/async drop glue generation support for - [x] Trivially destructible types (integers, bools, floats, string slices, pointers, references, etc.) - [x] Arrays and slices (array pointer is unsized into slice pointer) - [x] ADTs (enums, structs, unions) - [x] tuple-like types (tuples, closures) - [ ] Dynamic types (`dyn Trait`, see explainer's [proposed design](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#async-drop-glue-for-dyn-trait)) - [ ] coroutines (rust-lang/rust#123948) - [x] Async drop glue includes sync drop glue code - [x] Cleanup branch generation for `async_drop_in_place_raw` - [ ] Union rejects non-trivially async destructible fields - [ ] `AsyncDrop` implementation requires same bounds as type definition - [ ] Skip trivially destructible fields (optimization) - [ ] New [`TyKind::AdtAsyncDestructor`](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#adt-async-destructor-types) and get rid of combinators - [ ] [Synchronously undroppable types](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#exclusively-async-drop) - [ ] Automatic async drop at the end of the scope in async context

bjorn3 · 2024-05-20T09:55:24Z

compiler/rustc_codegen_ssa/src/mir/block.rs

+            ty::InstanceDef::DropGlue(_, None)
+            | ty::InstanceDef::AsyncDropGlueCtorShim(_, None)
+            | ty::InstanceDef::AsyncDropGlue(_, None),
+        ) = def {


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) => {

?

Implement `needs_async_drop` in rustc and optimize async drop glue This PR expands on rust-lang#121801 and implements `Ty::needs_async_drop` which works almost exactly the same as `Ty::needs_drop`, which is needed for rust-lang#123948. Also made compiler's async drop code to look more like compiler's regular drop code, which enabled me to write an optimization where types which do not use `AsyncDrop` can simply forward async drop glue to `drop_in_place`. This made size of the async block from the [async_drop test](https://github.com/zetanumbers/rust/blob/67980dd6fb11917d23d01a19c2cf4cfc3978aac8/tests/ui/async-await/async-drop.rs) to decrease by 12%.

rustbot · 2024-06-30T20:41:27Z

The Miri subtree was changed

cc @rust-lang/miri

azhogin · 2024-06-30T21:23:37Z

Async drop glue re-worked to use drop elaboration plus StateTransform for async_drop_in_place poll function generation.
@rustbot review

RalfJung · 2024-07-01T06:09:08Z

src/tools/miri/tests/pass/async-drop.rs

Seems like now there is no more Miri test of this feature at all?

rust-log-analyzer · 2024-07-02T11:11:17Z

The job x86_64-gnu-llvm-17 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

 - LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 46)
 - LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 49)
 - LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 61)
##[endgroup]
Setting extra environment values for docker:  --env ENABLE_GCC_CODEGEN=1 --env GCC_EXEC_PREFIX=/usr/lib/gcc/
[CI_JOB_NAME=x86_64-gnu-llvm-17]
---
sccache: Starting the server...
##[group]Configure the build
configure: processing command line
configure: 
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--llvm-root=/usr/lib/llvm-17', '--enable-llvm-link-shared', '--set', 'rust.thin-lto-import-instr-limit=10', '--set', 'change-id=99999999', '--enable-verbose-configure', '--enable-sccache', '--disable-manage-submodules', '--enable-locked-deps', '--enable-cargo-native-static', '--set', 'rust.codegen-units-std=1', '--set', 'dist.compression-profile=balanced', '--dist-compression-formats=xz', '--set', 'rust.lld=false', '--disable-dist-src', '--release-channel=nightly', '--enable-debug-assertions', '--enable-overflow-checks', '--enable-llvm-assertions', '--set', 'rust.verify-llvm-ir', '--set', 'rust.codegen-backends=llvm,cranelift,gcc', '--set', 'llvm.static-libstdcpp', '--enable-new-symbol-mangling']
configure: target.x86_64-unknown-linux-gnu.llvm-config := /usr/lib/llvm-17/bin/llvm-config
configure: llvm.link-shared     := True
configure: rust.thin-lto-import-instr-limit := 10
configure: change-id            := 99999999

bors · 2024-07-02T22:59:51Z

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

oli-obk · 2024-07-04T09:11:21Z

First async drop glue implementation re-worked to use the same drop elaboration code as for sync drop.

Please do that in a separate PR instead of mixing it with the automatic-async-drop changes

rustbot assigned oli-obk Apr 15, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Apr 15, 2024

bjorn3 reviewed Apr 15, 2024

View reviewed changes

compiler/rustc_middle/src/ty/instance.rs Outdated Show resolved Hide resolved

zetanumbers mentioned this pull request Apr 15, 2024

Add simple async drop glue generation #121801

Merged

16 tasks

petrochenkov mentioned this pull request Apr 16, 2024

MCP: Low level components for async drop rust-lang/compiler-team#727

Closed

3 tasks

RalfJung reviewed Apr 16, 2024

View reviewed changes

zetanumbers reviewed Apr 19, 2024

View reviewed changes

azhogin force-pushed the azhogin/async-drop branch 2 times, most recently from e12d2c6 to cdf91ab Compare April 21, 2024 22:39

zetanumbers reviewed Apr 22, 2024

View reviewed changes

zetanumbers mentioned this pull request May 3, 2024

Implement needs_async_drop in rustc and optimize async drop glue #124662

Merged

bjorn3 reviewed May 20, 2024

View reviewed changes

zetanumbers mentioned this pull request Jun 14, 2024

Tracking Issue for async drop codegen #126482

Open

20 tasks

petrochenkov added the F-async_drop Async drop label Jun 17, 2024

oli-obk added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 28, 2024

azhogin force-pushed the azhogin/async-drop branch from c9aacfe to 025a613 Compare June 30, 2024 20:41

rustbot added the WG-trait-system-refactor The Rustc Trait System Refactor Initiative label Jun 30, 2024

azhogin changed the title ~~Async drop codegen (WIP)~~ Async drop codegen Jun 30, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 30, 2024

RalfJung reviewed Jul 1, 2024

View reviewed changes

src/tools/miri/tests/pass/async-drop.rs Outdated

Copy link

Member

RalfJung Jul 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like now there is no more Miri test of this feature at all?

Async drop codegen with async drop glue through templated coroutine

5c28592

azhogin force-pushed the azhogin/async-drop branch from 025a613 to 5c28592 Compare July 2, 2024 11:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Async drop codegen #123948

Async drop codegen #123948

azhogin commented Apr 15, 2024 •

edited

Loading

rustbot commented Apr 15, 2024

rustbot commented Apr 15, 2024

slanterns commented Apr 15, 2024

azhogin commented Apr 15, 2024

RalfJung Apr 16, 2024 •

edited

Loading

azhogin Apr 21, 2024

RalfJung Apr 22, 2024

RalfJung Apr 16, 2024

azhogin Apr 21, 2024

zetanumbers Apr 19, 2024

azhogin Apr 21, 2024

zetanumbers commented Apr 19, 2024

zetanumbers Apr 22, 2024

bjorn3 May 20, 2024

rustbot commented Jun 30, 2024

azhogin commented Jun 30, 2024

RalfJung Jul 1, 2024

rust-log-analyzer commented Jul 2, 2024

bors commented Jul 2, 2024

oli-obk commented Jul 4, 2024

Async drop codegen #123948

Are you sure you want to change the base?

Async drop codegen #123948

Conversation

azhogin commented Apr 15, 2024 • edited Loading

rustbot commented Apr 15, 2024

rustbot commented Apr 15, 2024

slanterns commented Apr 15, 2024

azhogin commented Apr 15, 2024

RalfJung Apr 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zetanumbers commented Apr 19, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rustbot commented Jun 30, 2024

azhogin commented Jun 30, 2024

Choose a reason for hiding this comment

rust-log-analyzer commented Jul 2, 2024

bors commented Jul 2, 2024

oli-obk commented Jul 4, 2024

azhogin commented Apr 15, 2024 •

edited

Loading

RalfJung Apr 16, 2024 •

edited

Loading