serde
serde copied to clipboard
serde-rs
de: Make flattened structs and aliases interact correctly.
The issue is that FlatStructAccess has no access to the aliases of the struct it's deserializing.
Ideally we'd try to serialize the key rather than checking whether we're going to use it before-hand, then actually take the value out, but that happens to be tricky with the current seed API.
So we need to somehow get the aliased names back to FlatStructAccess. Introduce a serialize_struct-like API that takes them in a backwards-compatible way. For parallelism, and since we also support aliases on enum variants, also extend the struct_variant API in a similar way. I'm open to better ways to fix it, but I can't think of any other that isn't a breaking change...
Fixes #1504.
That's sort-of a breaking change, plus other serialize_struct implementations that use the fields use it as a hint to pre-allocate storage, which in the case of aliases may vastly over-allocate.
Ah, I haven't heard of Deserializer impls pre-allocating storage based on deserialize_struct. Do you have an example of a format like that? Ordinarily it would be the other way around; the Deserializer impl is aware how much data is in the input, and the Deserialize impl needs to pre-allocate based on MapAccess::size_hint.
Blerg, I was misreading code (was reading Serializer impls indeed).
But searched for a bit and found bits that would look at best fishy with that change. For example bincode serializes structs as tuples, and takes fields.len():
- https://searchfox.org/mozilla-central/rev/06578bfadb5bdc5faee81f7e9b3c3fed21e616e0/third_party/rust/bincode/src/de/mod.rs#361
I haven't dug about whether this would break bincode for sure. I'm happy to dig out a bit. If it's just lying about a too large size hint it may be ok I guess....
Is there any change to the status of this PR? I just ran into this issue in one of my projects, and it would be nice to have it fixed assuming this implementation covers all bases
Same here. It's August and no movement. @dtolnay @emilio can this conversation be resuscitated or should we take up the mantle?
Ran into this while trying to make field name changes in a backward-compatible way.
