#[inline(never)] does not work for async functions

[michaelwoerister]

I would expect the following code produced a Future::poll() impl with the noinline attribute.

#![feature(noop_waker)]

use std::task::{Context, Waker, Poll};
use std::future::Future;

#[inline(never)]
pub async fn foo() -> u32 {
    std::hint::black_box(1)
}

pub fn bar() -> Poll<u32> {
    let f = std::pin::pin!(foo());
    f.poll(&mut Context::from_waker(Waker::noop()))
}

Instead, the poll method has inlinehint applied to it and gets inlined accordingly:

; This is the function creating the async fn obj:
; Function Attrs: noinline nonlazybind uwtable
define i8 @_RNvCs8Nh0J9OTdDr_15async_fn_inline3foo() unnamed_addr #2 {
  %1 = alloca [1 x i8], align 1
  store i8 0, ptr %1, align 1
  %2 = load i8, ptr %1, align 1
  ret i8 %2
}

; This the poll method:
; Function Attrs: inlinehint nonlazybind uwtable <== this should arguably be noinline too
define internal { i32, i32 } @_RNCNvCs8Nh0J9OTdDr_15async_fn_inline3foo0B3_(...)

Meta

rustc --version --verbose:

rustc 1.82.0-nightly (636d7ff91 2024-08-19)
binary: rustc
commit-hash: 636d7ff91b9847d6d43c7bbe023568828f6e3246
commit-date: 2024-08-19
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 19.1.0

[compiler-errors]

I feel like it's actually up for debate whether #[inline] on an async fn should apply to the function item itself (that produces the future) or the poll function of the coroutine that the item returns. This distinction matters, and it's a subtlety that's not really possible to clearly distinguish with the current inline syntax.

[michaelwoerister]

I agree that that's not clear. It would be great, however, if there was some way to control the inlining behavior of the poll function.

[compiler-errors]

I can agree about that!

[traviscross]

@rustbot labels +T-lang +I-lang-nominated

We discussed this during WG-async triage. On the one hand, this is an optimization, so it seems like a compiler issue. But there's also a lang issue hiding in here:

To what does the attribute apply?

That's probably a lang question. So let's lang nominate it and discuss.

Our feeling on the WG-async call was that the attribute should probably apply semantically to both the function that constructs the future and to the constructed poll function. We felt in particular that the current behavior of it not applying to the poll function is surprising and less useful.

And we felt that if people needed more control than that, the suggestion would be that they desugar the async fn into #[inline(..)] fn .. -> impl Future<..> { #[inline(..)] async { .. }}.

What does the team think?

[nikomatsakis]

I said this in the meeting but this is an interesting question that is related to the "flavors" RFC I recently opened. I think it implies that #[inline] should be something you can put on async blocks. I think when you put it on an async function, it should go on the poll (same with applying it to an async closure). The general principle is that this attribute should apply to "where the code is" in all cases.

This suggests that if you REALLY want control, you can desugar like so

#[inline(always)]
async fn foo() -> T { ... }

// becomes

fn foo() -> async -> T {
    #[inline(always)] // <-- this goes here
    async move { ... }
}

This implies you can add attributes on the fn foo explicitly now.

[traviscross]

@rfcbot fcp merge

We talked about this in the lang call today. We want attributes like this to apply to "where the code is", i.e. to the poll function in this case.

The wrapper function, on the other hand, should always be inlined.

@rustbot labels -I-lang-nominated

[traviscross]

@rfcbot cancel

[rfcbot]

@traviscross proposal cancelled.

[traviscross]

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[nikomatsakis]

@rfcbot reviewed

[tmandry]

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[scottmcm]

The wrapper function, on the other hand, should always be inlined.

I'll note that that's the default, thanks to #116505, so from a lowering perspective nothing should be needed for that. Notable, it should not be inline(always), which would just unnecessarily penalize debug-mode compile-time. (Explicitly #[inline] would be fine, but probably not worth bothering.)

@rfcbot reviewed

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.