Another instance of #110338 (pretty similar to #71723 I guess). Code sample:
pub fn serve() -> impl Future<Output = ()> + Send {
async move {
let netstack = Foo;
let stream = futures::stream::iter(vec![]);
let work_items_fut =
// async move {
stream.for_each(|()| async {
let _ns = netstack.clone();
})
// .await }
;
let mut _fut0 = MaybeDone::Future(work_items_fut);
let mut _fut0 = unsafe { core::pin::Pin::new_unchecked(&mut _fut0) };
_fut0.await
}
}
playground
error: implementation of `std::marker::Send` is not general enough
--> src/lib.rs:24:5
|
24 | / async move {
25 | | let netstack = Foo;
26 | | let stream = futures::stream::iter(vec![]);
27 | | let work_items_fut =
... |
38 | | _fut0.await
39 | | }
| |_____^ implementation of `std::marker::Send` is not general enough
|
= note: `std::marker::Send` would have to be implemented for the type `&'0 Foo`, for any lifetime `'0`...
= note: ...but `std::marker::Send` is actually implemented for the type `&'1 Foo`, for some specific lifetime `'1`
error[[E0308]](https://doc.rust-lang.org/stable/error_codes/E0308.html): mismatched types
--> src/lib.rs:24:5
|
24 | / async move {
25 | | let netstack = Foo;
26 | | let stream = futures::stream::iter(vec![]);
27 | | let work_items_fut =
... |
38 | | _fut0.await
39 | | }
| |_____^ one type is more general than the other
|
= note: expected `async` block `[async block@src/lib.rs:29:38: 31:18]`
found `async` block `[async block@src/lib.rs:29:38: 31:18]`
For more information about this error, try `rustc --explain E0308`.
error: could not compile `playground` due to 2 previous errors
What's interesting about this one to me is that uncommenting the commented lines (wrapping in an async move) removes the error.
The projection type being in MaybeDone is load-bearing, so I suspect something like #92449 would have fixed this.
Another instance of #110338 (pretty similar to #71723 I guess). Code sample:
playground
What's interesting about this one to me is that uncommenting the commented lines (wrapping in an
async move) removes the error.The projection type being in
MaybeDoneis load-bearing, so I suspect something like #92449 would have fixed this.