New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revisit of the representation of adjacently tagged enums tag #2505
Revisit of the representation of adjacently tagged enums tag #2505
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can confirm this looks promising. Thanks!
serde_derive/src/de.rs
Outdated
let expecting = format!("enum {}", tag); | ||
quote_block! { | ||
#[doc(hidden)] | ||
struct __FieldVariant(pub __Field); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect this whole type to go in serde::__private::de
instead of emitting a whole new type and set of trait impls into every single use of adjacently tagged enums.
pub struct AdjacentlyTaggedEnumVariant<F> {
tag: &'static str,
variants: &'static [&'static str],
fields_enum: PhantomData<F>,
}
impl<'de, F> DeserializeSeed<'de> for AdjacentlyTaggedEnumVariant<F>
where
F: Deserialize<'de>,
{
type Value = F;
...
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's what I wanted to do in the first place, but I just looked at Deserialize
and because it don't take self
I just moved on and did not thought of DeserializeSeed, I did something like this for serialization
I did not realised that Does something like this seams more appropriate ? |
Is there a crate implementing a binary format that use I've looked into |
I don't know of any. But if there is, then yes, we would have heard about it breaking from #2475. |
This PR is still marked as draft. Are there concrete changes planned (what are they?), or was this supposed to be ready for review? |
@dtolnay I just forgot to open it for review, there is no changes planned |
There is conflicts needed to be resolved, I'm gonna need some time to understand why thoses changes has been made and what can I do to not break anything. |
All conflicts were related to the removal of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
5671c6b
to
957ef20
Compare
…#471) Update adjacent enum non-roundtrip tests to match serde-rs/serde#2505
This PR has some breaking changes that results in failing tests in quick-xml (tafia/quick-xml#630) |
Also see serde-rs/serde#2496 Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
* Bump serde from 1.0.180 to 1.0.183 in /lang/rust Bumps [serde](https://github.com/serde-rs/serde) from 1.0.180 to 1.0.183. - [Release notes](https://github.com/serde-rs/serde/releases) - [Commits](serde-rs/serde@v1.0.180...v1.0.183) --- updated-dependencies: - dependency-name: serde dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> * Update the Serde impl after serde-rs/serde#2505 Also see serde-rs/serde#2496 Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org> --------- Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
* Bump serde from 1.0.180 to 1.0.183 in /lang/rust Bumps [serde](https://github.com/serde-rs/serde) from 1.0.180 to 1.0.183. - [Release notes](https://github.com/serde-rs/serde/releases) - [Commits](serde-rs/serde@v1.0.180...v1.0.183) --- updated-dependencies: - dependency-name: serde dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> * Update the Serde impl after serde-rs/serde#2505 Also see serde-rs/serde#2496 Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org> --------- Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Martin Tzvetanov Grigorov <mgrigorov@apache.org> (cherry picked from commit e26943f)
Recent Serde changes ([1], [2]) changed the internal representation of enums, breaking our test. [1]: serde-rs/serde#2496 [2]: serde-rs/serde#2505
Recent Serde changes ([1], [2]) changed the internal representation of enums, breaking our test. [1]: serde-rs/serde#2496 [2]: serde-rs/serde#2505
…ron-rs#471) Update adjacent enum non-roundtrip tests to match serde-rs/serde#2505
…ron-rs#471) Update adjacent enum non-roundtrip tests to match serde-rs/serde#2505
Since this is a breaking change, why was it released as a patch instead of a minor version? v1.0.180In my case, an enum #[derive(Serialize, Deserialize, Debug)]
#serde(tag = "type", content = "data")]
enum Message {
A(i32),
}
let m = Message::A(100); was rmp_serded to [130, 164, 116, 121, 112, 101, 161, 65, 164, 100, 97, 116, 97, 100] which the JS msgpack package converts to JSON as
with serde v1.0.180. v1.0.181Same enum and attributes, rmp_serde spits out [130, 164, 116, 121, 112, 101, 129, 161, 65, 192, 164, 100, 97, 116, 97, 100] and JS msgpack converts to {
"type": {
"A": null
},
"data": 100
} serde_jsonWhat is further confusing this is that converting this to JSON with serde_json results in
regardless of the serde version. rmp_serdeWith serde v1.0.180 the result of
JS msgpack decodes that to JSON like so {
"type": "request",
"data": {
"param": 100
}
} And with serde v1.0.181 the msgpack encoded byte array is
which JS msgpack decodes to {
"type": {
"0": null
},
"data": {
"param": 100
}
} Can you please shed light on this? @dtolnay @Baptistemontan |
This PR is a follow on #2496.
This is a proof of concept to evaluate if such feature would be interesting.
I've run some tests with
serde_json
and the output is the same, but still allow some format to take advantage ofvariant_index
during serialization.If it looks promising I can continue to work on it