WG-async meeting agenda

• Meeting date: 2024-10-03

Attendance

• People: TC, eholk, yosh

Meeting roles

• Minutes:

Scheduled meetings

None.

Update these here.

Proposed meetings

None.

Update these here.

Announcements or custom items

(Meeting attendees, feel free to add items here!)

Untriaged issues

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

Link: https://github.com/rust-lang/rust/issues/129347

eholk: Perhaps file this under "reasons why async fn was a mistake?"

eholk: Maybe we should pick a reasonable default and then say you can desugar manually to control what the attribute applies to.
This approach means we'd have to allow #[inline] on async { }.

// for maximum control, you should be allowed to add either attribute at your option

#[inline(never)]
fn foo() -> impl Future<Output = ()> {
    #[inline(never)]
    async {
        ()
    }
}

• Probably want this to apply to both the function and to poll.
• Probably want people to desugar if they need better control than that.

"async code fails to compile with -Znext-solver" rust#129865

Link: https://github.com/rust-lang/rust/issues/129865

We replied to the submitter asking for a self-standing reproduction.

"Bogus "implementation of <whatever trait you want> is not general enough" with RPITIT + async" rust#130113

Link: https://github.com/rust-lang/rust/issues/130113

We're replying with the tracking issues that lists all of these duplicates and near-duplicates.

"Outlives requirements are not implied in the return type of async fn, and generally for RPIT" rust#130935

Link: https://github.com/rust-lang/rust/issues/130935

fn f<'a, T>() -> impl Future<Output = &'a T> {
    async { loop {} }
    //~^ ERROR the parameter type `T` may not live long enough
}

This is OK:

fn f<'a, T: 'a>() -> impl Future<Output = &'a T> {
    async { loop {} }
}

This is also OK:

fn f<'a, T>() -> &'a T {
    loop {}
}

But this is not OK:

async fn f<'a, T>() -> &'a T {
    //~^ ERROR the parameter type `T` may not live long enough
    loop {}
}

This is about the behavior of implied bounds.

"ICE: index out of bounds, instrument coverage" rust#131190

Link: https://github.com/rust-lang/rust/issues/131190

Interesting!

Interesting aside

Bonus points for explaining why this is true…

struct S;
impl From<Box<()>> for S {
    fn from(_: Box<()>) -> Self { S }
}

fn main() {
    let x: Box<_> = loop {};
    //let _: S = x.into(); //~ ERROR type annotations needed
    // Receivers:
    // - Box<_>
    // - &Box<_>
    // - &mut Box<_>
    // - _ (?0) // <--- ERROR
    // - &?0
    // - &mut ?0
    let _: S = <_>::into(x); //~ OK
}

Nominated RFCs, PRs, and issues

"Generic Futures" rfcs#3434

Link: https://github.com/rust-lang/rfcs/pull/3434

"Tracking Issue for task::Waker::noop" rust#98286

Link: https://github.com/rust-lang/rust/issues/98286

"Rename AsyncIterator back to Stream, introduce an AFIT-based AsyncIterator trait" rust#119550

Link: https://github.com/rust-lang/rust/pull/119550

"Clarification needed on what happens when Future::poll wakes an old waker" rust#119698

Link: https://github.com/rust-lang/rust/issues/119698

"Overly conservative async capture analysis when values are borrowed" rust#129325

Link: https://github.com/rust-lang/rust/issues/129325

"Context reactor hook" libs-team#347

Link: https://github.com/rust-lang/libs-team/issues/347

WG RFCs, PRs, and issues nominated for T-lang/T-types

None.

Pending PRs on the WG-async repo

None.

S-waiting-on-team

"Rename AsyncIterator back to Stream, introduce an AFIT-based AsyncIterator trait" rust#119550

Link: https://github.com/rust-lang/rust/pull/119550

Proposed FCPs

Check your boxes!

None.

Active FCPs

None.

P-critical issues

None.

WG-async work project board

https://github.com/orgs/rust-lang/projects/29/views1/d