upgraded software that used serde-xml-rs v0.3.0 to use v0.6.0.
It compiled fine but parsing broke.
found out that parsing still works on 0.4.1
investigated what happens and built a minimal test case
the self.is_map_value is true after parsing the <enumerationDefinition> which when continuing, inside read_inner_value (), skips the StartElement of the next xml item (<messageDefinition>) and then is confused because the enum Definition has no variant for <field> items.
changing the order of the XML elements actually makes it parseable again 🤔
point 6. made me believe this is a bug and self.is_map_value should be reset when a new StartElement is coming up for an enum - since I don't fully grok the description what this struct field really does for read_inner_value(), please double verify this is all good. All tests succeed, so I guess my fix is fine and has no side-effects?
I'll adapt this patch however needed, I do realise this is more of a bug report including a potential fix than a PR. I'd like to advocate though to keep the test case of this PR at least please :)
I ran into this head-scratcher today, history:
self.is_map_value
is true after parsing the<enumerationDefinition>
which when continuing, insideread_inner_value ()
, skips the StartElement of the next xml item (<messageDefinition>
) and then is confused because theenum Definition
has no variant for<field>
items.point 6. made me believe this is a bug and
self.is_map_value
should be reset when a new StartElement is coming up for an enum - since I don't fully grok the description what this struct field really does forread_inner_value()
, please double verify this is all good. All tests succeed, so I guess my fix is fine and has no side-effects?I'll adapt this patch however needed, I do realise this is more of a bug report including a potential fix than a PR. I'd like to advocate though to keep the test case of this PR at least please :)