Compile error: static lifetime not satisfied but it is

[Skepfyr]

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

[inquisitivecrystal]

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

[fee1-dead]

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

[Skepfyr]

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

cargo-bisect-rustc reports 6 bors merge commits:

• 2020-10-05UTC: Auto merge of Working branch-level code coverage #77080 - richkadel:llvm-coverage-counters-2, r=tmandry
• 2020-10-06UTC: Auto merge of Rollup of 13 pull requests #77606 - JohnTitor:rollup-7rgahdt, r=JohnTitor
• 2020-10-06UTC: Auto merge of Implement advance_by, advance_back_by for iter::Chain #77594 - timvermeulen:chain_advance_by, r=scottmcm
• 2020-10-06UTC: Auto merge of Separate projection bounds and predicates #73905 - matthewjasper:projection-bounds-2, r=nikomatsakis
• 2020-10-06UTC: Auto merge of Add a command to install a git hook to automatically run x.py test tidy --bless #76356 - caass:hooks, r=jyn514
• 2020-10-06UTC: Auto merge of Support static linking with glibc and target-feature=+crt-static #77386 - joshtriplett:static-glibc, r=petrochenkov

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]

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

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

[apiraino]

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

@rustbot label -I-prioritize +P-high

[compiler-errors]

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

[pnkfelix]

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.

[matthewjasper]

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