The number 4096 is used to cap the size of collections that we preallocate.
cmp::min(hint.unwrap_or(0), 4096)
I find this number more understandable than 0x1000.
The custom one was functionally identical to the default implementation given by
the Deserialize trait. If someone has benchmarks that the custom one performs
better, we can put it back.
Serde's `ContentDeserializer` and `ContentRefDeserializer`
cannot deserialize struct enum variant associated data when
that data is encoded as a sequence. This failure leads to
errors when decoding an enum nested in another untagged
enum. For example:
#[derive(Serialize, Deserialize)]
#[serde(untagged)]
enum Foo {
A(Bar),
}
#[derive(Serialize, Deserialize)]
enum Bar {
B{f1: String},
}
let data1 = Foo::A(Bar::B{f1: "Hello".into()});
let bytes = rmp_serde::to_vec(&data1).unwrap();
let data2 = rmp_serde::from_slice::<Foo>(&bytes).unwrap();
Deserializing fails with the error `Syntax("data did not
match any variant of untagged enum Foo")`, but the
underlying failure occurs when decoding the associated data
of `Bar::B`.
This pull request fixes the issue by allowing
`ContentDeserializer` and `ContentRefDeserializer` to
deserialize sequence-encoded struct enum variant data.
During serialization, internally tagged enums invoke the Serializer's
serialize_struct. In JSON this turns into a map which uses visit_map
when deserialized. But some formats employ visit_seq when
deserializing a struct. One example is rmp-serde. Such formats were
previously unable to deserialize an internally tagged enum. This
change fixes it by adding visit_seq for internally tagged enums.
