Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Async Closures Support #18591

Closed
Veykril opened this issue Dec 3, 2024 · 7 comments · Fixed by #18594
Closed

Async Closures Support #18591

Veykril opened this issue Dec 3, 2024 · 7 comments · Fixed by #18594
Assignees
Labels
Broken Window Bugs / technical debt to be addressed immediately C-tracking-issue Category: tracking issue

Comments

@Veykril
Copy link
Member

Veykril commented Dec 3, 2024

We don't really support them at all right now I believe and they are going to be stabilized soon so we should at least implement them well enough to prevent diagnostics from cropping up. #16173 might be relevant here

rust-lang/rust#132706

@Veykril Veykril added C-tracking-issue Category: tracking issue Broken Window Bugs / technical debt to be addressed immediately labels Dec 3, 2024
@ChayimFriedman2
Copy link
Contributor

@rustbot claim

@ChayimFriedman2
Copy link
Contributor

Actually @Veykril we seem to support them well - do you know any specific problem?

@Veykril
Copy link
Member Author

Veykril commented Dec 3, 2024

The main issues seems to be handling impl AsyncFn*

fn f(it: impl AsyncFn(u32) -> i32) {
    let it = it(0); // 	we error on this call
}

as plain closures we do handle them well enough (lowering them to impl Fn* -> impl Future (even though thats kind of wrong)

@ChayimFriedman2
Copy link
Contributor

So... to fully handle it we require support from chalk (since it knows closures implements the fn traits), but this is only required for where bounds, which we don't currently report diagnostics for, and we can handle invocations ourselves.

@Veykril
Copy link
Member Author

Veykril commented Dec 3, 2024

Alternatively We might be able to hack lowering of AsyncFn(...) -> T into Fn(...) -> impl Future<T>, that would suffice for our purposes as well. The main thing we need before stabilization is getting rid of diagnostics and resolve the return type when the thing is called. Implementing the whole thing shouldn't be necessary fortunately to get a good enough experience

@ChayimFriedman2
Copy link
Contributor

Alternatively We might be able to hack lowering of AsyncFn(...) -> T into Fn(...) -> impl Future<T>, that would suffice for our purposes as well. The main thing we need before stabilization is getting rid of diagnostics and resolve the return type when the thing is called. Implementing the whole thing shouldn't be necessary fortunately to get a good enough experience

That would be harder I believe since we would have to hook into how Chalk resolves trait bounds, or handle them specifically somewhere in name resolution. Anyway I put a PR.

@compiler-errors
Copy link
Member

Thanks for working on this @ChayimFriedman2.

Regarding AsyncFn*, as long as async || {} continues to just lower into || async {} in r-a, then I think all that is needed is a built-in blanket impl that looks conceptually like impl<F, Fut> AsyncFn for F where F: Fn() -> Fut, Fut: Future {}. I'd be happy to review a chalk PR that implements such an impl.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Broken Window Bugs / technical debt to be addressed immediately C-tracking-issue Category: tracking issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants