Repository navigation
#[inline(never)] does not work for async functions #129347
Description
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
Reacted by ecryth
Activity
compiler-errors commentedon Aug 21, 2024
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 commentedon Aug 21, 2024
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 commentedon Aug 21, 2024
I can agree about that!
traviscross commentedon Oct 3, 2024
@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
pollfunction. We felt in particular that the current behavior of it not applying to thepollfunction 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 fninto#[inline(..)] fn .. -> impl Future<..> { #[inline(..)] async { .. }}.What does the team think?
29 remaining items
Rollup merge of rust-lang#149245 - xacrimon:acrimon/async-fn-inline-a…
Rollup merge of rust-lang#149245 - xacrimon:acrimon/async-fn-inline-a…
Auto merge of #149245 - xacrimon:acrimon/async-fn-inline-attr, r=saet…
Rollup merge of rust-lang#149245 - xacrimon:acrimon/async-fn-inline-a…
Auto merge of #149245 - xacrimon:acrimon/async-fn-inline-attr, r=saet…
Rollup merge of rust-lang#149245 - xacrimon:acrimon/async-fn-inline-a…
Auto merge of #149245 - xacrimon:acrimon/async-fn-inline-attr, r=saet…
Rollup merge of rust-lang#149245 - xacrimon:acrimon/async-fn-inline-a…
Rollup merge of rust-lang#149245 - xacrimon:acrimon/async-fn-inline-a…
Rollup merge of rust-lang#149245 - xacrimon:acrimon/async-fn-inline-a…
Auto merge of #149245 - xacrimon:acrimon/async-fn-inline-attr, r=saet…
Rollup merge of rust-lang#149245 - xacrimon:acrimon/async-fn-inline-a…
Unrolled build for #149245 in rollup 165436
Rollup merge of #149245 - xacrimon:acrimon/async-fn-inline-attr, r=sa…