quick-xml

quick-xml copied to clipboard

It's impossible to depend on quick-xml/serialize without depending on serde/derive

Details: #472

@loyd , could you please describe, how you faced with this problem? You tried to use quick-xml in a crate with resolver="2" field?

I've fixed fixnum to support <tag>42.42</tag> parsing (by implementing visit_map). fixnum doesn't use serde/derive.

So, now it's fixed by enabling serde/derive.

But it also requires serde/derive in dev-dependencies, but it's inconvenient and allows to fail in the future (because not all feature combinations are checked by clippy, a lot of them).

Btw, next_key() cannot parse into &str (and next_value() too until v0.24 version). But it's a subject of another issue.

I've almost done with rewriting

Btw, next_key() cannot parse into &str (and next_value() too until v0.24 version). But it's a subject of another issue.

Yes, that is known problem

I've fixed fixnum to support <tag>42.42</tag> parsing (by implementing visit_map).

The problem with map is that deserialization performed using deserialize_any. It have many drawbacks for non-self-describing deserializers and deserializers with weak type systems. XML has only two types: string and map, and <tag>42.42</tag> is mapped to map!["$value" -> "42.42"].

Unfortunately, your code will break in one of next quick-xml release, because I plan to rename $value key to #text (actually split it into #text and #content as described in https://github.com/tafia/quick-xml/issues/383#issuecomment-1120244201).

@loyd, can you please post exact instruction, what I should do to reproduce that? I didn't see a resolver="2" field in the fixnum Cargo.toml

The problem with map is that deserialization performed using deserialize_any. It have many drawbacks for non-self-describing deserializers and deserializers with weak type systems.

Yep, a previous version uses deserialize_str for human-readable formats. But I need to support both parsing from str and from f64, so I've changed to deserialize_any.

Unfortunately, your code will break in one of next quick-xml release, because I plan to rename $value key to #text

It's ok, just specify it in the changelog explicitly.

@loyd, can you please post exact instruction, what I should do to reproduce that? I didn't see a resolver="2" field in the fixnum Cargo.toml

resolver="2" is for facing the problem in quick-xml. So, steps (in quick-xml repo):

• Add resolver = "2" to quick-xml (or edition = "2021").
• Run cargo clippy --features serde

It works fine with v1 because there is serde/derive dev-dep

I can reproduce this issue with these commands in an empty directory:

cargo init
echo 'quick-xml = { version = "0.26.0", features = [ "serialize" ] }' >> Cargo.toml
cargo build

By additionally issuing the below command, cargo build succeeds.

echo 'serde = { version = "1.0", features = [ "serde_derive" ] }' >> Cargo.toml

Alternatively checking out quick-xml locally, adding the features = [ "serde_derive" ] to the serde dependency in quick-xml's Cargo.toml is another way to work around this issue.

EDIT: I now understand that the issue description already covers most of this, sorry I did not realize this earlier.

I can reproduce this issue with these commands in an empty directory:

cargo init
echo 'quick-xml = { version = "0.26.0", features = [ "serialize" ] }' >> Cargo.toml
cargo build

I can confirm that #524 fixes this.