-
Notifications
You must be signed in to change notification settings - Fork 172
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
Deserialization for VarZeroVec<VarZeroSlice>, take 2 #3649
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We were wondering where the slice came from
@@ -154,7 +72,7 @@ where | |||
where | |||
D: Deserializer<'de>, | |||
{ | |||
let visitor: VarZeroVecVisitor<T, F> = VarZeroVecVisitor::default(); | |||
let visitor = VarZeroVecVisitor::<T, F>::default(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this actually different code 👀?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, the former still runs some type resolution in picking a deserialize impl. It picked wrong.
@@ -167,6 +85,7 @@ where | |||
impl<'de, 'a, T, F> Deserialize<'de> for &'a VarZeroSlice<T, F> | |||
where | |||
T: VarULE + ?Sized, | |||
Box<T>: Deserialize<'de>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we use a VarZeroSliceRefVisitor, we can get rid of this bound entirely. Not sure if that's worth an entirely separate Visitor, though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's fair; I think it[s fine because it ought to be pretty rare to want to deserialize this anyway. It's kinda a code smell to not support human readable deserialization, and the code optimizes away anyway since the choice is known at compile time.
#3643
I noticed that the error included Rust slices (
[T]
):which should absolutely not be getting introduced at any point here. The trait resolver is getting sufficiently confused when looking for an impl and it goes and looks at the
Box<[T]>: Deserialize
from the serde crate. It then continues to confuse itself. I think this is a trait resolver bug.The fix is to be very specific about which deserialize impl is being called within these impls.