-
-
Notifications
You must be signed in to change notification settings - Fork 793
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
Multiple impl
s or where
clauses satisfying Ty: Deserialize<'_>
found
#2418
Comments
you can try using I'm assuming this is related to your |
This is a longstanding rustc bug (rust-lang/rust#34979). As recommended in https://rust-lang.github.io/api-guidelines/future-proofing.html#c-struct-bounds, you should never write |
I have the same issue. Starting with this code everything works: use serde::{Serialize, Deserialize};
#[derive(Debug, Serialize, Deserialize)]
struct A<'a>(&'a [u8]);
#[derive(Debug, Serialize, Deserialize)]
struct B;
trait DataInner: {}
impl<'a> DataInner for A<'a> {}
impl DataInner for B {}
#[derive(Debug, Serialize, Deserialize)]
struct Data<T: DataInner> {
header: u8,
inner: T,
}
// C is unrelated to Data/DataInner and so Data<C> should not be a valid type.
#[derive(Debug, Serialize, Deserialize)]
struct C; Now, I want to enforce that all implementers of the use serde::{Serialize, Deserialize};
#[derive(Debug, Serialize, Deserialize)]
struct A<'a>(&'a [u8]);
#[derive(Debug, Serialize, Deserialize)]
struct B;
trait DataInner<'a>: Serialize + Deserialize<'a> {}
impl<'a> DataInner<'a> for A<'a> {}
impl<'a> DataInner<'a> for B {}
#[derive(Debug, Serialize, Deserialize)]
struct Data<'a, T: DataInner<'a>> {
header: u8,
inner: &'a T,
}
// C is unrelated to Data/DataInner and so Data<C> should not be a valid type.
#[derive(Debug, Serialize, Deserialize)]
struct C; This fails to compile with the error:
|
I have an issue where a struct field is a trait. I tried to use a generic implementation. But now I get an error when using derive, as seen below.
If I remove the derive and implement it manually it seems to be fixed (although I haven't tried it when it's fully implemented).
Is this a bug or am I overseeing something?
The text was updated successfully, but these errors were encountered: