de: Make flattened structs and aliases interact correctly.

[emilio]

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.

[emilio]

r? @dtolnay

[dtolnay]

Thanks! Would it be sufficient to pass the aliases in the fields given to deserialize_struct instead? I would prefer to avoid adding new Deserializer methods for this.

[emilio]

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.

[dtolnay]

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.

[emilio]

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....

[dmarcuse]

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

[jnicholls]

Same here. It's August and no movement. @dtolnay @emilio can this conversation be resuscitated or should we take up the mantle?

[KeyboardDanni]

Ran into this while trying to make field name changes in a backward-compatible way.

[dtolnay]

Fixed a different way by #2387.