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
Bug: untagged union fails to deserialize hashmap with usize as keys #1103
Comments
odesenfans
added a commit
to Moonsong-Labs/cairo-vm
that referenced
this issue
Jan 14, 2024
Problem: Deserializing the PIE additional data as a hashmap of `BuiltinAdditionalData` enums because of an issue with deserializing untagged unions in `serde` (see serde-rs/json#1103). Solution: add a new `AdditionalData` struct with explicit fields for each builtin, circumventing the untagged union issue. This solution has the advantage of always associating the correct data type for each builtin (it's not possible anymore to associate a builtin with a different data type), but requires modifications if a new builtin is added.
odesenfans
added a commit
to Moonsong-Labs/cairo-vm
that referenced
this issue
Jan 18, 2024
Problem: Deserializing the PIE additional data as a hashmap of `BuiltinAdditionalData` enums because of an issue with deserializing untagged unions in `serde` (see serde-rs/json#1103). Solution: add a new `AdditionalData` struct with explicit fields for each builtin, circumventing the untagged union issue. This solution has the advantage of always associating the correct data type for each builtin (it's not possible anymore to associate a builtin with a different data type), but requires modifications if a new builtin is added.
odesenfans
added a commit
to Moonsong-Labs/cairo-vm
that referenced
this issue
Jan 30, 2024
Problem: Deserializing the PIE additional data as a hashmap of `BuiltinAdditionalData` enums because of an issue with deserializing untagged unions in `serde` (see serde-rs/json#1103). Solution: add a new `AdditionalData` struct with explicit fields for each builtin, circumventing the untagged union issue. This solution has the advantage of always associating the correct data type for each builtin (it's not possible anymore to associate a builtin with a different data type), but requires modifications if a new builtin is added.
odesenfans
added a commit
to Moonsong-Labs/cairo-vm
that referenced
this issue
Feb 21, 2024
Problem: Deserializing the PIE additional data as a hashmap of `BuiltinAdditionalData` enums because of an issue with deserializing untagged unions in `serde` (see serde-rs/json#1103). Solution: add a new `AdditionalData` struct with explicit fields for each builtin, circumventing the untagged union issue. This solution has the advantage of always associating the correct data type for each builtin (it's not possible anymore to associate a builtin with a different data type), but requires modifications if a new builtin is added.
odesenfans
added a commit
to Moonsong-Labs/cairo-vm
that referenced
this issue
Feb 22, 2024
Problem: Deserializing the PIE additional data as a hashmap of `BuiltinAdditionalData` enums because of an issue with deserializing untagged unions in `serde` (see serde-rs/json#1103). Solution: add a new `AdditionalData` struct with explicit fields for each builtin, circumventing the untagged union issue. This solution has the advantage of always associating the correct data type for each builtin (it's not possible anymore to associate a builtin with a different data type), but requires modifications if a new builtin is added.
odesenfans
added a commit
to Moonsong-Labs/cairo-vm
that referenced
this issue
Mar 7, 2024
Problem: Deserializing the PIE additional data as a hashmap of `BuiltinAdditionalData` enums because of an issue with deserializing untagged unions in `serde` (see serde-rs/json#1103). Solution: add a new `AdditionalData` struct with explicit fields for each builtin, circumventing the untagged union issue. This solution has the advantage of always associating the correct data type for each builtin (it's not possible anymore to associate a builtin with a different data type), but requires modifications if a new builtin is added.
odesenfans
added a commit
to Moonsong-Labs/cairo-vm
that referenced
this issue
Mar 27, 2024
Problem: Deserializing the PIE additional data as a hashmap of `BuiltinAdditionalData` enums because of an issue with deserializing untagged unions in `serde` (see serde-rs/json#1103). Solution: add a new `AdditionalData` struct with explicit fields for each builtin, circumventing the untagged union issue. This solution has the advantage of always associating the correct data type for each builtin (it's not possible anymore to associate a builtin with a different data type), but requires modifications if a new builtin is added.
odesenfans
added a commit
to Moonsong-Labs/cairo-vm
that referenced
this issue
Apr 4, 2024
Problem: Deserializing the PIE additional data as a hashmap of `BuiltinAdditionalData` enums because of an issue with deserializing untagged unions in `serde` (see serde-rs/json#1103). Solution: add a new `AdditionalData` struct with explicit fields for each builtin, circumventing the untagged union issue. This solution has the advantage of always associating the correct data type for each builtin (it's not possible anymore to associate a builtin with a different data type), but requires modifications if a new builtin is added.
odesenfans
added a commit
to Moonsong-Labs/cairo-vm
that referenced
this issue
Apr 7, 2024
Problem: Deserializing the PIE additional data as a hashmap of `BuiltinAdditionalData` enums because of an issue with deserializing untagged unions in `serde` (see serde-rs/json#1103). Solution: add a new `AdditionalData` struct with explicit fields for each builtin, circumventing the untagged union issue. This solution has the advantage of always associating the correct data type for each builtin (it's not possible anymore to associate a builtin with a different data type), but requires modifications if a new builtin is added.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I think I found an issue related to the deserialization of hashmaps in an untagged enum. I have a struct that contains a
HashMap<usize, usize>
:This struct is used in an enum and I want to deserialize to that enum type:
My problem is the following. When deserializing an example, deserializing to
T
works but deserializing toE
fails. This appears to be due to the fact that the untagged enum deserializer does not make the connection between the string keys and theusize
keys of the hashmap. However, iirc, following the JSON standard keys should always be strings.Is this a known issue? Am I missing something?
The text was updated successfully, but these errors were encountered: