Description
I don't know for sure, but this feels like an interaction between method dispatch, deref, and possibly Send
.
Here's a fairly minimal reproduction of the issue: (Playground)
use std::rc::Rc;
use rayon::prelude::*;
fn main() {
let x = vec![Rc::new(12)];
let y: Vec<_> = x.into_par_iter().collect();
}
The error message in question:
error[E0599]: no method named `into_par_iter` found for type `std::vec::Vec<std::rc::Rc<{integer}>>` in the current scope
--> src/main.rs:8:23
|
8 | let y: Vec<_> = x.into_par_iter().collect();
| ^^^^^^^^^^^^^ method not found in `std::vec::Vec<std::rc::Rc<{integer}>>`
|
= note: the method `into_par_iter` exists but the following trait bounds were not satisfied:
`[std::rc::Rc<{integer}>] : rayon::iter::IntoParallelIterator`
The type of x
is Vec<Rc<i32>>
. Rayon has an impl with the following signature:
impl<T: Send> IntoParallelIterator for Vec<T> { ... }
The problem here is that Vec<Rc<i32>>: IntoParallelIterator
is not satisfied because Rc<i32>: Send
is not satisfied.
Because Vec<Rc<i32>>
derefs to [Rc<i32>]
, the error message lists that as the trait bound to be satisfied. This is very unhelpful because there is no way you could ever satisfy that constraint.
While fixing the message to also list Vec<Rc<i32>>
in addition to [Rc<i32>]
would be helpful, it doesn't help solve the actual problem which is that Rc<i32>
is not Send
. The code I initially ran into this with had an Rc
about ~15 structs down, so it was not obvious at all what the problem was until I looked at the relevant impl in the rayon docs and added the following to my code:
fn foo<T: Send>() {}
foo::<MyType>();
Once I did that, I got a full error message that nicely lists the entire stack of obligations that led to Send
not being fulfilled.
It would be very helpful if the compiler could tell me that Rc<i32>: Send
is not satisfied so I could skip all of those steps. (Rc<i32>: Send
in my minimal example, MyType: Send
in actual code)