-
Notifications
You must be signed in to change notification settings - Fork 7
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
Serialisation regression in #1183 #1270
Comments
Not sure this is the regression as described. The issue in reality appears to be hinted at by the error message
Since #[derive(Serialize, Deserialize)]
struct Unit;
#[derive(Serialize, Deserialize)]
#[serde(tag = "u")]
enum UnitOrNot {
Unit(Unit),
NotUnit { field: String },
}
#[derive(Serialize, Deserialize)]
struct Nested {
#[serde(flatten)]
inner: UnitOrNot,
}
let data = r#"
[
{
"u": "NotUnit",
"field": "value",
"ignored": "bar"
},
{
"u": "Unit",
"ignored": "foo"
}
]"#;
let _: Vec<Nested> = serde_json::from_str(data).unwrap(); The first element of the array deserializes correctly but the second throws:
Worth reporting as a serde bug? It may be a known edge case interaction of unit struct/flatten/internal tagging. In the mean-time, believing |
Fixes #1270 A simpler test json might be better but kept the original just to show it is fixed. BREAKING CHANGE: `ops::Module` no longer unit struct, must be constructed with `new()` or `default()`
Serde issue: serde-rs/serde#2775 |
(skip serializing, deserialize to None) non-breaking patch for #1270
) (skip serializing, deserialize to None) Closes #1270
Fixes #1270 A simpler test json might be better but kept the original just to show it is fixed. BREAKING CHANGE: `ops::Module` no longer unit struct, must be constructed with `new()` or `default()`
) (skip serializing, deserialize to None) Closes #1270
Fixes #1270 without keeping the unused `input_extensions` field. BREAKING CHANGE: `ops::Module` no longer unit struct, must be constructed with `new()` or `default()`
#1183 included a breaking change to the serialisation format, removing the
input_extensions
field from the operations.This should have either been a new
v2
serialisation with backwards compatibility, or implemented so that the field gets silently ignored (if possible).This json was generated by
guppylang 0.5.2
(which useshugr-py v0.2.0a1
). Since it includes the input extensions fields it produces errors when decoded with the latesthugr
crate, but works correctly once the fields are removed.https://gist.github.com/aborgna-q/f4d6caa1fd7f9b5288935f39df4d4918
The text was updated successfully, but these errors were encountered: