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

Compile error: static lifetime not satisfied but it is #86172

Open
Skepfyr opened this issue Jun 9, 2021 · 8 comments
Open

Compile error: static lifetime not satisfied but it is #86172

Skepfyr opened this issue Jun 9, 2021 · 8 comments
Labels
A-lifetimes Area: Lifetimes / regions C-bug Category: This is a bug. P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-async Working group: Async & await

Comments

@Skepfyr
Copy link
Contributor

Skepfyr commented Jun 9, 2021

I tried this code:

use std::{
    future::Future,
    marker::PhantomData,
    {pin::Pin, sync::Arc},
};

fn validate_signature() -> impl Future<Output = ()> + Send {
    let certificate_store = Cache::<CertificateRetriever>::new();
    let res = Box::pin(async move {
        certificate_store.get().await;
    });
    fn foo<T: 'static>(_c: &T) {}
    res
}

type CertificateRetriever =
    Arc<dyn Retrieve<Future = Pin<Box<dyn Future<Output = ()> + Send + 'static>>>>;

trait Retrieve: Send + Sync {
    type Future: Future<Output = ()> + Send + 'static;

    fn get(&self) -> Self::Future;
}

impl<R: Retrieve + ?Sized> Retrieve for Arc<R> {
    type Future = R::Future;

    fn get(&self) -> Self::Future {
        todo!()
    }
}

struct Cache<R: Retrieve> {
    marker: PhantomData<R>,
}

impl<R> Cache<R>
where
    R: Retrieve + 'static,
{
    fn new() -> Self {
        todo!()
    }
    async fn get(&self) {
        self.get_value().await
    }

    fn get_value(&self) -> R::Future {
        todo!()
    }
}

Playground

I expected to see this to compile fine, minor changes to the code cause it to compile.

Instead, I get this error:

error[E0477]: the type `Pin<Box<dyn Future<Output = ()> + Send>>` does not fulfill the required lifetime
 --> src/lib.rs:7:28
  |
7 | fn validate_signature() -> impl Future<Output = ()> + Send {
  |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: type must satisfy the static lifetime

error: aborting due to previous error

This may be a duplicate of #80052 but as it involves no associated constants I'm keeping it separate for now.
Compiled with rustc 1.52.1

@Skepfyr Skepfyr added the C-bug Category: This is a bug. label Jun 9, 2021
@inquisitivecrystal
Copy link
Contributor

@rustbot label +A-lifetimes +E-needs-mcve +T-compiler

@rustbot rustbot added A-lifetimes Area: Lifetimes / regions E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 9, 2021
@fee1-dead
Copy link
Member

fee1-dead commented Jun 13, 2021

I cannot minimize further:

use std::{future::Future, pin::Pin};

trait Foo: Send + Sync {
    type F: Future<Output = ()> + Send + 'static;
}

impl<R: Foo + ?Sized> Foo for Box<R> {
    type F = R::F;
}

fn a<R: Foo>() -> R::F { todo!() }
async fn b<R: Foo>() {
    a::<R>().await
}

fn c() -> impl Future<Output = ()> + Send {
    type A = Box<dyn Foo<F = Pin<Box<dyn Future<Output = ()> + Send + 'static>>>>;
    Box::pin(async {
        b::<A>().await;
    })
}

@rustbot label -E-needs-mcve

@rustbot rustbot removed the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Jun 13, 2021
@Skepfyr
Copy link
Contributor Author

Skepfyr commented Jun 14, 2021

I bisected using the above repro to find the regression in nightly-2020-10-07.

cargo-bisect-rustc reports 6 bors merge commits:

Looking through those my best guess is that this is caused by #73905.

This suggests it is different from #80052 as I don't believe it has ever compiled, and it definitely works on both sides of this regression.

@inquisitivecrystal
Copy link
Contributor

inquisitivecrystal commented Jun 14, 2021

Ahh, another one. #73905 caused a lot of problems.

@rustbot label I-prioritize +regression-from-stable-to-stable

@rustbot rustbot added I-prioritize Issue: Indicates that prioritization has been requested for this issue. regression-from-stable-to-stable Performance or correctness regression from one stable version to another. labels Jun 14, 2021
@apiraino
Copy link
Contributor

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-high

@rustbot rustbot added P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Jun 17, 2021
@compiler-errors
Copy link
Member

So removing the + Send makes the error go away -- this might be related to #71723 et al.

@pnkfelix
Copy link
Member

Visiting for P-high review

I recommend that this be first handed off to wg-async to investigate, with the advice that they in turn should feel free to hand it off again to T-types if they determine that this isn't really async/generator specific.

@pnkfelix pnkfelix added the WG-async Working group: Async & await label Nov 18, 2022
@matthewjasper
Copy link
Contributor

I've had a look at this and it's definitely another case of #71723, caused by the additional requirements for normalizing <dyn A<X=Y> as A>::X added in #73905

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: Lifetimes / regions C-bug Category: This is a bug. P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-async Working group: Async & await
Projects
None yet
Development

No branches or pull requests

8 participants