Async function generates potentially panicking code

[ZhekaS]

It appears that async fn() {...} desugars into Future state machine with a possible panic!() path. I understand that this path is taken if poll() is executed on a finished task. This is a problem when trying to write a panic-free code (that is with no panic-related code linked to the final artifact).
I was not able to write a minimal reproducing example, so I will put here the excerpts from my full code (no_std, attempting to implement custom executor):

pub async fn async_number() -> u32 {
    42
}

pub async fn example_task() {
    let num = async_number().await;
    let _ = writeln!(dbg_print::DebugPrint, "Async number: {}", num);
}

This produces the following llvm-ir:

; test_futures::example_task::{{closure}}
; Function Attrs: inlinehint minsize nounwind optsize
define internal noundef zeroext i1 @"_ZN12test_futures12example_task28_$u7b$$u7b$closure$u7d$$u7d$17h69ea2006b28af955E"(ptr nocapture noundef nonnull align 1 %_1, ptr noalias nocapture readnone align 4 %_2) unnamed_addr #4 !dbg !1446 {
start:
  %_14 = alloca [0 x i8], align 1
  %args = alloca [8 x i8], align 4
  %_15 = alloca [24 x i8], align 4
  %num = alloca [4 x i8], align 4
  // ...................
  %0 = load i8, ptr %_1, align 1, !dbg !1477, !range !1478, !noundef !17
  switch i8 %0, label %bb7 [
    i8 0, label %bb4.thread
    i8 1, label %panic
    i8 3, label %bb4
  ], !dbg !1477

// ........

panic.i:                                          ; preds = %bb4
; call core::panicking::panic_const::panic_const_async_fn_resumed
  tail call fastcc void @_ZN4core9panicking11panic_const28panic_const_async_fn_resumed17h3b19b0997d8ed2ccE() #12, !dbg !1505
  unreachable, !dbg !1505

In the final disassembly the call to panic_const_async_fn_resumed() appears as well.

I am not sure what would be the right way to solve this. Perhaps introducing Future::try_poll() ? Or adding a "Finished" variant to the Poll enum.

UPDATE:
I believe the code responsible for generating the panic block is this:

rust/compiler/rustc_mir_transform/src/coroutine.rs

Lines 1254 to 1264 in a885811

	if can_return {
	let block = match transform.coroutine_kind {
	CoroutineKind::Desugared(CoroutineDesugaring::Async, _)
	| CoroutineKind::Coroutine(_) => {
	// For `async_drop_in_place<T>::{closure}` we just keep return Poll::Ready,
	// because async drop of such coroutine keeps polling original coroutine
	if tcx.is_async_drop_in_place_coroutine(body.source.def_id()) {
	insert_poll_ready_block(tcx, body)
	} else {
	insert_panic_block(tcx, body, ResumedAfterReturn(transform.coroutine_kind))
	}

It is also documented:

rust/compiler/rustc_mir_transform/src/coroutine.rs

Lines 43 to 46 in a885811

	//! One of them is the implementation of `Coroutine::resume` / `Future::poll`.
	//! For coroutines with state 0 (unresumed) it starts the execution of the coroutine.
	//! For coroutines with state 1 (returned) and state 2 (poisoned) it panics.
	//! Otherwise it continues the execution from the last suspension point.

However it does not change the fact that async/await is not panic-free-friendly.

[zachs18]

I am not sure what would be the right way to solve this. Perhaps introducing Future::try_poll() ? Or adding a "Finished" variant to the Poll enum.

I don't think either of these will necessarily fix the issue.

• Adding Future::try_poll wouldn't completely fix the issue since Future::poll still exists and needs to do something with completed compiler-generated Futures (though I suppose dead-code elimination could help here)
• Poll is stable and not #[non_exhaustive] so we can't add a variant to it.

---

We could perhaps add a compiler flag/attribute to make async blocks/fns/closures simply return Poll::Pending indefinitely after they complete.

Or maybe we could do this unconditionally in release mode, i.e. gate the behavior on cfg(debug_assertions). This could maybe be justified as "polling a (compiler-generated) future after it has completed is a bug, just like integer overflow is a bug, but it is only caught/reported when debug_assertions are enabled".

Doing this might not even technically be a breaking change? I don't know if there's anywhere that says specifically what happens if an async fn/async block/async closure is polled after completion, other than Future's docs which are explicitly vague to allow different behavior (source):

Panics

Once a future has completed (returned Ready from poll), calling its poll method again may panic, block forever, or cause other kinds of problems; the Future trait places no requirements on the effects of such a call. [...]

[ZhekaS]

I don't think either of these will necessarily fix the issue.

• Adding Future::try_poll wouldn't completely fix the issue since Future::poll still exists and needs to do something with completed compiler-generated Futures (though I suppose dead-code elimination could help here)

Dead-code elimination that's it. Much of panic-free code is built upon it anyway. It would be up to the executor to opt to use poll() or try_poll(). If the trait Future would provide some trivial default implementation for try_poll() it won't be a breaking change as far as I can tell... However it will need a separate RFC I guess (well, I am not that well versed in specific policies...).

[ds84182]

We could perhaps add a compiler flag/attribute to make async blocks/fns/closures simply return Poll::Pending indefinitely after they complete.

This is the behavior I'd expect from compiler generated futures and I'm surprised that they panic instead.

[ultimaweapon]

For me I prefer panic instead of Poll::Pending to catch the bug instead of having a headache why some futures never complete.

[GrigorenkoPV]

We could perhaps add a compiler flag/attribute to make async blocks/fns/closures simply return Poll::Pending indefinitely after they complete.

I've filed a PR doing exactly that: #147129

[tmiasko]

This is a problem when trying to write a panic-free code (that is with no panic-related code linked to the final artifact).

There is an unstable panic strategy immediate-abort that traps execution immediately and avoids linking panic-related code. It requires rebuilding the standard library with build-std cargo feature.

[ZhekaS]

This is a problem when trying to write a panic-free code (that is with no panic-related code linked to the final artifact).

There is an unstable panic strategy immediate-abort that traps execution immediately and avoids linking panic-related code. It requires rebuilding the standard library with build-std cargo feature.

Good to know there is some work in this direction, but unfortunately even if this is eventually stabilized it isn't exactly a graceful way of handling failures. The business logic needs to have an opportunity to handle errors on case-by-case basis before panicking/aborting whatsoever.