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

Mysterious "higher-ranked lifetime error" with async fn in trait and return-type notation #110963

Open
compiler-errors opened this issue Apr 28, 2023 · 4 comments
Labels
A-higher-ranked Area: Higher-ranked things (e.g., lifetimes, types, trait bounds aka HRTBs) A-NLL Area: Non-lexical lifetimes (NLL) C-bug Category: This is a bug. D-confusing Diagnostics: Confusing error or lint that should be reworked. F-async_fn_in_trait Static async fn in traits F-return_type_notation `#[feature(return_type_notation)]` requires-nightly This issue requires a nightly compiler in some way. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@compiler-errors
Copy link
Member

I tried this code:

#![feature(return_type_notation)]
#![feature(async_fn_in_trait)]

trait HealthCheck {
    async fn check<'a: 'a>(&'a mut self) -> bool;
}

async fn do_health_check_par<HC>(hc: HC)
where
    HC: HealthCheck<check(): Send> + Send + 'static,
{
    tokio::task::spawn(async move {
        let mut hc = hc;
        if !hc.check().await {
            log_health_check_failure().await;
        }
    });
}

async fn log_health_check_failure() {}

I expected to see this happen: it works

Instead, this happened:

error: higher-ranked lifetime error
  --> src/lib.rs:12:5
   |
12 | /     tokio::task::spawn(async move {
13 | |         let mut hc = hc;
14 | |         if !hc.check().await {
15 | |             log_health_check_failure().await;
16 | |         }
17 | |     });
   | |______^
   |
   = note: could not prove `[async block@src/lib.rs:12:24: 17:6]: Send`
@compiler-errors compiler-errors added A-NLL Area: Non-lexical lifetimes (NLL) C-bug Category: This is a bug. requires-nightly This issue requires a nightly compiler in some way. D-confusing Diagnostics: Confusing error or lint that should be reworked. F-async_fn_in_trait Static async fn in traits T-types Relevant to the types team, which will review and decide on the PR/issue. F-return_type_notation `#[feature(return_type_notation)]` labels Apr 28, 2023
@compiler-errors
Copy link
Member Author

compiler-errors commented Apr 28, 2023

Actually I forgot to click submit on this issue and I think I solved it in the mean time...

edit: didnt actually solve it completely, it still exists for early-bound lifetimes

@compiler-errors compiler-errors self-assigned this Apr 28, 2023
@compiler-errors compiler-errors removed their assignment Apr 28, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Apr 29, 2023
… r=cjgillot

Don't duplicate anonymous lifetimes for async fn in traits

`record_lifetime_params_for_async` needs to be called outside of the scope of the function, or else it'll end up collecting anonymous lifetimes twice (those on the function and those within the `AnonymousCreateParameter` rib). This matches how `record_lifetime_params_for_async` is being used for functions with bodies below.

This fixes (partially) rust-lang#110963 when the lifetimes are late-bound, but does not do so when the lifetimes are early-bound (as seen from the known-bug that I added).
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Apr 29, 2023
… r=cjgillot

Don't duplicate anonymous lifetimes for async fn in traits

`record_lifetime_params_for_async` needs to be called outside of the scope of the function, or else it'll end up collecting anonymous lifetimes twice (those on the function and those within the `AnonymousCreateParameter` rib). This matches how `record_lifetime_params_for_async` is being used for functions with bodies below.

This fixes (partially) rust-lang#110963 when the lifetimes are late-bound, but does not do so when the lifetimes are early-bound (as seen from the known-bug that I added).
@GlenDC
Copy link
Contributor

GlenDC commented Jul 27, 2023

What’s the status on this? Can I help progress this? With some mentoring I do not mind volunteering dev time to help moving F-async_fn_in_trait Static async fn in traits further and getting it to hopefully something stable this year.

@compiler-errors
Copy link
Member Author

compiler-errors commented Jul 27, 2023

The fix for this is not clear, possibly related to a far more general problem with async (#110338), and probably not mentorable unfortunately :(

This issue is not blocking async fn in trait stabilization, though.

@GlenDC
Copy link
Contributor

GlenDC commented Jul 27, 2023

Ok. Does seem like an easy issue to run into for which I do not see a workaround. But I’ll trust you at your word. Thx!

@fmease fmease added the A-higher-ranked Area: Higher-ranked things (e.g., lifetimes, types, trait bounds aka HRTBs) label Sep 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-higher-ranked Area: Higher-ranked things (e.g., lifetimes, types, trait bounds aka HRTBs) A-NLL Area: Non-lexical lifetimes (NLL) C-bug Category: This is a bug. D-confusing Diagnostics: Confusing error or lint that should be reworked. F-async_fn_in_trait Static async fn in traits F-return_type_notation `#[feature(return_type_notation)]` requires-nightly This issue requires a nightly compiler in some way. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
Status: Non-blocking
Development

No branches or pull requests

3 participants