Implementation of trait is not general enough when used inside tokio::spawn

[gatesn]

I hit this in a reasonably large code base, so tried to strip this down to a somewhat minimal reproduction.

I don't really understand why this breaks inside the spawn block. The full definitions are in the linked playground.

#[tokio::main]
async fn main() {
    // This works fine
    let mut foo = MyWriter { writer: vec![] };
    foo.write(SOME_FOO).await.unwrap();

    // This complains that implementation of `Buf` is not general enough
    tokio::spawn(async move {
        let mut foo = MyWriter { writer: vec![] };
        foo.write(SOME_FOO).await.unwrap();
    })
    .await
    .unwrap();
}

Resulting in

    = note: `&'0 [u8]` must implement `writer::test::Buf`, for any lifetime `'0`...
    = note: ...but `writer::test::Buf` is actually implemented for the type `&'static [u8]`

Rust Playground

[steffahn]

Ah, we had this sort of issue only recently on the forum. It’s actually related to the Send bound. A terribly annoying compiler bug, not only because it’s unnecessarily struggling to deduce the Send here, but more-so because the error message gives zero indication about it.

Here you can see how the issue comes and goes with a T: Send:

#[tokio::main]
async fn main() {
    // This works fine
    let mut foo = MyWriter { writer: vec![] };
    foo.write(SOME_FOO).await.unwrap();

    send(async move {
        let mut foo = MyWriter { writer: vec![] };
        foo.write(SOME_FOO).await.unwrap();
    });
}

fn send<T>(x: T)
where
    T: Send, // comment out this line and it compiles ...
{
}

One way to fix these quite reliably seems to be to apply some type erasure, and box the right thing, in this case boxing the right Future seems to work well [in the other thread, it was a Stream that could be boxed]:

+ use futures::FutureExt;
…

    tokio::spawn(async move {
        let mut foo = MyWriter { writer: vec![] };
-       foo.write(SOME_FOO).await.unwrap();
+       foo.write(SOME_FOO).boxed().await.unwrap();
    })
    .await
    .unwrap();

If you aren’t using the futures crate (or at least the futures-util part of it), you can of course also do this without the convenience .boxed() method,

    tokio::spawn(async move {
        let mut foo = MyWriter { writer: vec![] };
        (Box::pin(foo.write(SOME_FOO))
            as std::pin::Pin<Box<dyn Future<Output = io::Result<_>> + Send>>)
            .await
            .unwrap();
    })
    .await
    .unwrap();

but the simplicity of .boxed() will of course make it easier - especially when you need to experiment a bit until you find the best place(s) to add it.

[PonasKovas]

I seem to be hitting this same exact issue in my (also rather big) codebase. Could you expand on what exactly is the issue here? And are there any other solutions? My case is pretty hot and I don't think boxing random futures would be acceptable.

[steffahn]

I don't really understand the root of the issue either beyond noticing that it's a compiler bug.

Of course it's annoying to introduce boxing and dynamic function calls just for working around it.

I have some ideas of what else to try out, let me get to this later. (Not at home ATM.)

[steffahn]

Yes, I have actually found a nice solution now.

Trying out a few things, I think I’ve found out that the only actually relevant property of these boxed, type-erased futures/streams – which made them an effective workaround for this compiler bug & error – is that they implement Send unconditionally.

So turns out: a wrapper type struct AlwaysSend<Fut> with an unconditional impl<Fut> Send for AlwaysSend<Fut> (not restricted to Fut: Send) can offer the same effect, even when Fut is still the original future type and some poll method directly delegates to it; without introducing any boxing, or type erasure with dynamic calls; so there should be no overhead at all.

Of course, Send is relevant for soundness

---

But wait!! it suffices to enforce the Fut: Send thing when constructing the wrapper, so there we have a way to encapsulate this workaround wrapper type in a safe API.

[This mirrors the property of dyn Future<…> + Send being always Send itself, but when you construct it, you’ll need to prove the thing you’ve actually put in is Send.]

For simplicity, I’ve just uploaded such a type to crates.io now. The crate even offers a similarly convenient API through its own extension traits FutureExt and StreamExt. So in places where adding a call to .boxed() might help as I’ve explained above, instead a call to .always_send() in the right place(s) should solve your issue equally well

[jumpnbrownweasel]

@steffahn

Yes, I have actually found a nice solution now.

You really did!! Congrats.

[steffahn]

Ah, I finally found a good explanation of the actual underlying issue, too:

rust-lang/rust#102211 (comment)

@Yandros

[Replying to @emersonford's post here since it seems more appropriate]

---

nice post @emersonford

Regarding:

What's not immediately clear to me though is why this is so specific to auto traits + generators. Even if you don't need to prove Send for the generator, don't you still need to prove that Trait is implemented for fn(&'static ()) inside of the generator interior? I.e., why does

It's specific to:

1. generators, because they're one place where the lifetimes used by the resulting type/enum that makes the Future are erased: Rust does not have the tools to express self-referential lifetimes, so to avoid being unsound with the "made up" lifetimes that can end up populating the compiler-generated self-referential datastructure backing generators / async, the compiler straight up erases them somehow so as to prevent lifetime-specific impls from applying (since in certain scenarios this could be unsound);
2. auto-traits since they:
   • leak through -> impl Trait / existential trait abstractions (that is, contrary to other traits which are just stated explicitly as part of the -> impl Trait contract, so that they can be checked within the right context, auto-traits are not enforced there and then, and instead checked later on, in a context with erased lifetimes;
   • in a structural manner, meaning it delegates to each generator capture implementing the trait, as you mentioned, which brings us to 1.

---

Now, the culprit triggering this is indeed the associated type, <T as Trait>::Assoc. At that point, even if the data structure itself (Foo in my example) unconditionally requires T : Trait, the trait checker will nonetheless try to prove this again, and this time with the added difficulty of having erased lifetimes, even the 'static lifetime.

Workaround for library authors

Is then not to use associated types.

That is, replacing:

struct Foo<T : Trait>(
    T::Assoc,
);

with:

struct Foo<T : Trait<Assoc = R>, R = <T as Trait>::Assoc>(
    R,
    ::core::marker::PhantomData<T>,
);

that is, we introduce a new type R, which defaults to T::Assoc, and we also require that T::Assoc be equal to R. All in all, inference should work just as well, and basically anything else too, but for the type now containing a fully standalone R type. This will avoid the requirement to check T : Trait within an erased-lifetime scenario.

Illustration

Using .flat_map(|x| x) instead of .flatten() dodges the issues, even though they are semantically equivalent. The difference is that flatten does mention <I as Iterator>::Item, whereas flat_map uses a fresh U type parameter which is only constrained to be F::Output for extra trait implementations.

---

Potentially interesting?

Since using struct X(fn(&'static ()); dodges the issue too (since the X "type constructor" is no longer a "type with a movable lifetime within in"), I got curious about trying to formalize stuff using hand-rolled type constructors, i.e., HKTs:

trait WithLifetime<'a> { type T; }
type Feed<'a, T : WithLifetime<'a>> = T::T;
trait HKT = for<'a> WithLifetime<'a>;

type A = dyn for<'a> WithLifetime<'a, T = fn(&'static ())>;
type B = dyn for<'a> WithLifetime<'a, T = fn(&'a ())>;

• with macro sugar:

  type A = HKT!(<'a> = fn(&'static ());
  type B = HKT!(<'a> = fn(&'a ());
  

Here, we have A and B both being fully-fledged types, but which happen to express a form of <'a>-genericity, which could be expressed in the following pseudo-code, sort to speak:

type A<'a> = fn(&'static ());
type B<'a> = fn(&'a ());

And doing that, we could then replace struct Foo<T>(<T as Trait>::Assoc) where T : Trait; definition with:

/// Idea: replace `T` with `Feed<'static, T_>`, for some `T_ : <'_>` "generic generic" type.
struct Foo<T_ : ?Sized + HKT>(
    <Feed<'static, T_> as Trait>::Assoc,
)
where
    Feed<'static, T_> : Trait,
;

With that, using Foo::<A> fails, but using Foo::<B> does not fail, even though they both amount to the same T = fn(&'static ()).

• I think the distinction stems from A "capturing" 'static, and thus being detected by the lifetime-eraser heuristic,
• whereas B does not capture anything on its own: it's just its associated type which does, but after being queried with a fed 'static to the WithLifetime trait. And somehow that lifetime in as WithLifetime<'static> does not get erased