Skip to content
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

Open
odesenfans opened this issue Jan 10, 2024 · 0 comments
Open

Comments

@odesenfans
Copy link

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>:

#[derive(Deserialize, Debug)]
struct T {
    h: HashMap<usize, usize>,
}

This struct is used in an enum and I want to deserialize to that enum type:

#[derive(Deserialize, Debug)]
#[serde(untagged)]
enum E {
    T(T),
    // Other variants omitted
}

My problem is the following. When deserializing an example, deserializing to T works but deserializing to E fails. This appears to be due to the fact that the untagged enum deserializer does not make the connection between the string keys and the usize keys of the hashmap. However, iirc, following the JSON standard keys should always be strings.

#[test]
fn test_serde_untagged() {
    let s = "{\"h\": {\"1\": 2, \"3\": 4}}";

    // Works
    let t: T = serde_json::from_str(s).unwrap();
    println!("{:?}", t);
    
    // Fails
    let e: E = serde_json::from_str(s).unwrap();
    println!("{:?}", e);
}

Is this a known issue? Am I missing something?

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
Labels
None yet
Development

No branches or pull requests

1 participant