Adjacently tagged enums don't work in formats not supporting string values

[inetic]

I'm using the bencode format which doesn't differentiate between strings and bytes.

In particular I'm working with serde-bencode which currently has a test ser_de_flattened_adjacently_tagged_enum ignored due of this issue.

The test fails with the error InvalidType("Invalid Type: byte array (expected: string or map)") coming from serde/ContentDeserializer::deserialize_enum.

Before returning the error, the self.content variable contains Content::ByteBuf(b"Request") instead of a string.

Applying the below patch in that function seems to resolve the issue, but I'm not too familiar with the serde code so please let me know if you think this is or isn't an adequate solution (full diff here).

-                s @ Content::String(_) | s @ Content::Str(_) => (s, None),
+                s @ Content::String(_)
+               | s @ Content::Str(_)
+               | s @ Content::ByteBuf(_)
+               | s @ Content::Bytes(_) => (s, None),

For posterity, adjacently tagged enums worked OK in serde-bencode with serde v1.0.180 but broke with >=v1.0.181.

[Mingun]

Could you check if #2811 solves this problem?

[inetic]

Could you check if https://github.com/serde-rs/serde/pull/2811 solves this problem?

Sorry to say, but no. The same serde-bencode tests ([1], [2]) fail with your branch as with the upstream with a slightly different error message.

[Mingun]

It seems that the thing that broke serde-bencode is #2496 and #2505. This change broke several protocols

[oli-obk]

Applying the below patch in that function seems to resolve the issue, but I'm not too familiar with the serde code so please let me know if you think this is or isn't an adequate solution (full diff here).

I wonder whether we could just always let the format handle this and not reject any of the other Content variants.