-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Bad Error Message: error[E0277]: the trait bound T: Generator<ResumeTy>
is not satisfied
#79648
Comments
Reduced some (but it'd be nice to remove the use futures::stream;
use futures::stream::StreamExt;
use std::future;
struct Bar {}
impl Bar {
async fn get_foo<'a>(&self) -> Vec<Foo<'a>> {
let results = vec![()];
let foo: Vec<Foo<'a>> = stream::iter(results)
.filter_map(|_| async move { Some(Foo::new()) })
.filter(|m| future::ready(true))
.collect()
.await;
foo
}
}
struct Foo<'a> {
_use_a: &'a (),
}
impl<'a> Foo<'a> {
fn new() -> Foo<'a> {
Foo { _use_a: &() }
}
}
fn demand_is_send<T>(t: T)
where
T: Send,
{
}
fn main() {
let bar = Bar {};
demand_is_send(async move { bar.get_foo().await })
} @rustbot label A-async-await A-diagnostics |
The |
Further minimized for the remaining error.. playground use futures::stream;
use futures::stream::StreamExt;
use std::future::{self, Future};
fn get_foo<'a>() -> impl Future<Output = Vec<()>> + 'a {
async {
let results = vec![()];
let foo: Vec<()> = stream::iter(results)
.filter_map(|_| async move { Some(()) })
.filter(|m| future::ready(true))
.collect()
.await;
foo
}
}
fn demand_is_send<T>(t: T)
where T: Send
{}
fn main() {
demand_is_send(get_foo())
} Haven't tried removing the futures dep yet. |
I think I came across the same issue, but with a slightly different snippet of code: use futures::future::{join, ready, Future};
use futures::stream::{self, StreamExt};
fn f() -> impl Future<Output = ()> + Send {
async {
let a = &();
join(
stream::empty().for_each(|_: ()| async { drop(a) }),
ready(()),
)
.await;
}
}
When compiling on stable, I'm also getting the error about Curiously, the usage of |
One-crate repro: (playground) use std::future::Future;
use std::marker::PhantomData;
trait Stream {
type Item;
}
struct Filter<St: Stream> {
pending_item: St::Item,
}
fn filter<St: Stream>(_: St) -> Filter<St> {
unimplemented!();
}
struct FilterMap<Fut, F> {
f: F,
pending: PhantomData<Fut>,
}
impl<Fut, F> Stream for FilterMap<Fut, F>
where
F: FnMut() -> Fut,
Fut: Future,
{
type Item = ();
}
pub fn get_foo() -> impl Future + Send {
async {
let _y = &();
let _x = filter(FilterMap {
f: || async move { *_y },
pending: PhantomData,
});
async {}.await;
}
} |
Turns out having anything with any sort of lifetime in stream/sink chains will trigger nasty issues such as rust-lang/rust#79648 which is pretty difficult to figure out how to work around. Making `Topic` a newtype erases the lifetime from the type, making it significantly easier to work with in thsoe contexts.
Turns out having anything with any sort of lifetime in stream/sink chains will trigger nasty issues such as rust-lang/rust#79648 which is pretty difficult to figure out how to work around. Making `Topic` a newtype erases the lifetime from the type, making it significantly easier to work with in thsoe contexts.
Turns out having anything with any sort of lifetime in stream/sink chains will trigger nasty issues such as rust-lang/rust#79648 which is pretty difficult to figure out how to work around. Making `Topic` a newtype erases the lifetime from the type, making it significantly easier to work with in thsoe contexts.
Turns out having anything with any sort of lifetime in stream/sink chains will trigger nasty issues such as rust-lang/rust#79648 which is pretty difficult to figure out how to work around. Making `Topic` a newtype erases the lifetime from the type, making it significantly easier to work with in thsoe contexts.
This and #71723 look like the same thing. |
Turns out having anything with any sort of lifetime in stream/sink chains will trigger nasty issues such as rust-lang/rust#79648 which is pretty difficult to figure out how to work around. Making `Topic` a newtype erases the lifetime from the type, making it significantly easier to work with in thsoe contexts.
Is there any progress or workaround for this? |
CC #82921 |
Triage: current output (the bound being pointed at is new):
|
Triage: Current output (fallout from NLL stabilization):
|
Current output:
|
error message
Hello! This is a bug report for a confusing/bad error message:
code
I apologize that the following probably isn't the easiest way to trigger it. I am relatively new to Rust and am just now working with Generics and Lifetimes now which is how I got here. The following is a very stripped down version of my code (it compiles without the commented line).
main.rs
:Meta
rustc --version --verbose
:Cargo.toml
:This is my first bug report for a project of this size. Please let me know if you need me to modify anything. Thank you!
The text was updated successfully, but these errors were encountered: