has_flatten rework

[Mingun]

This PR removes workaround from #2794 in the first commit.

The 2nd commit unifies behaviour for all cases where flatten fields processed in the deserializer. Consequence of that commit: FlattenSkipDeserializing[DenyUnknown]

• does not collect data in Field, because do not read them anyway
• gets deserialize_in_place method
• gets ability to deserialize from sequence (visit_seq method)
• uses deserialize_struct instead of deserialize_map

The 3rd commit gives understandable message when derive failed due to assertion.

The 4th commit removed dead code that here since 2018.

The last commit does the unification of has_flatten behaviour for the serializer side. Consequence of that commit: FlattenSkipSerializing

• uses serialize_struct instead of serialize_map

[dtolnay]

Thanks!

This PR makes derive(Deserialize) ignore a flatten attribute on fields that have skip_deserializing, and derive(Serialize) ignore a flatten attribute on fields that have skip_serializing.

I would have to think whether that is the behavior that should be intended. It means that in the case of FlattenSkipSerializing and FlattenSkipDeserializing (using names from the test suite), we serialize using serialize_struct and deserialize using deserialize_map, or serialize using serialize_map and deserialize using deserialize_struct.

I think some users would expect that if a type is serialized using serialize_struct, it should be deserialized using deserialize_struct, and if a type is serialized using serialize_map, it should be deserialized using deserialize_map. I am not sure how sensitive various data formats are to this.

[Mingun]

Boundary between (de)serialize_struct and (de)serialize_map is already blurred when you use #[serde(flatten)]. Actually, that is source of pain because (de)serialize_map looses information which is important for some formats (see for example #1529). There is no good solution of this problem in current approach which pretends that simply using special (De)serializer will be enough to support flattening. The alternative design is outlined in my comment here.

I think, if you explicitly skip only (de)serialization method you understand consequences. I would say that the base expectation that if field is invisible for (de)serialization it does not affects the format.

[dtolnay]

Okay — makes sense.

Thank you!