Deserialization for VarZeroVec<VarZeroSlice>, take 2

[Manishearth]

#3643

I noticed that the error included Rust slices ([T]):

error[E0275]: overflow evaluating the requirement `Box<[_]>: Deserialize<'_>`
   --> utils/zerovec/src/varzerovec/serde.rs:103:66
    |
103 |             let deserialized: VarZeroVec<'a, T, F> = VarZeroVec::deserialize(deserializer)?;
    |                                                                  ^^^^^^^^^^^
    |
    = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`zerovec`)
note: required for `Box<varzerovec::slice::VarZeroSlice<[_], _>>` to implement `Deserialize<'_>`
   --> utils/zerovec/src/varzerovec/serde.rs:117:21

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.

[robertbastian]

We were wondering where the slice came from

[robertbastian]

Is this actually different code 👀?

[Manishearth]

yep, the former still runs some type resolution in picking a deserialize impl. It picked wrong.

[skius]

If we use a VarZeroSliceRefVisitor, we can get rid of this bound entirely. Not sure if that's worth an entirely separate Visitor, though

[Manishearth]

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.