#[serde(untagged)] no longer works correctly in serde versions 1.0.220 and above

[rxdiscovery]

Hello,

Since I upgraded the serde crate from version 1.0.219 to 1.0.224, the #[serde(untagged)] attribute no longer works.

Here is some code to run the tests :

use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize, Serialize, Clone)]
#[serde(untagged)]
pub enum WrapperStruct {
    Single(ValueStruct),
    Multiple(Vec<ValueStruct>),
}

#[derive(Debug, Deserialize, Serialize, Clone)]
pub enum ValueStruct {
    String(String),
    Integer(i64),
    Decimal(f64),
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // ---------------------- JSON
    println!("----------JSON----------");

    // Example 1: a single string value
    let json_single = r#"{"String": "hello"}"#;
    let single: WrapperStruct = serde_json::from_str(json_single)?;
    println!("Single: {:?}", single);

    // Example 2: a single numeric value (integer)
    let json_integer = r#"{"Integer": 42}"#;
    let integer: WrapperStruct = serde_json::from_str(json_integer)?;
    println!("Integer: {:?}", integer);

    // Example 3: multiple values
    let json_multiple = r#"[{"String": "hello"}, {"Integer": 123}, {"Decimal": 45.67}]"#;
    let multiple: WrapperStruct = serde_json::from_str(json_multiple)?;
    println!("Multiple: {:?}", multiple);

    // ---------------------- RON
    println!("----------RON----------");

    // Example 1: a single string value
    let ron_single = r#"String("hello")"#;
    let single: WrapperStruct = ron::from_str(ron_single)?;
    println!("Single: {:?}", single);

    // Example 2: a single integer value
    let ron_integer = r#"Integer(42)"#;
    let integer: WrapperStruct = ron::from_str(ron_integer)?;
    println!("Integer: {:?}", integer);

    // Example 3: multiple values
    let ron_multiple = r#"[String("hello"), Integer(123), Decimal(45.67)]"#;
    let multiple: WrapperStruct = ron::from_str(ron_multiple)?;
    println!("Multiple: {:?}", multiple);

    // Serialization back to RON
    let ron_output = ron::to_string(&multiple)?;
    println!("Serialized to RON: {}", ron_output);

    Ok(())
}

Results :

With serde version 1.0.219 :

[package]
name = "bug_serde"
version = "0.1.0"
edition = "2024"

[dependencies]
ron = "0.11.0"
serde = { version = "=1.0.219", features = ["derive"] }
serde_json = "1.0.132"

----------JSON----------
Single: Single(String("hello"))
Integer: Single(Integer(42))
Multiple: Multiple([String("hello"), Integer(123), Decimal(45.67)])
----------RON----------
Single: Single(String("hello"))
Integer: Single(Integer(42))
Multiple: Multiple([String("hello"), Integer(123), Decimal(45.67)])
Serialized to RON: [String("hello"),Integer(123),Decimal(45.67)]

---

With serde version 1.0.220 :

[package]
name = "bug_serde"
version = "0.1.0"
edition = "2024"

[dependencies]
ron = "0.11.0"
serde = { version = "1.0.220", features = ["derive"] }
serde_json = "1.0.132"

----------JSON----------
Single: Single(String("hello"))
Integer: Single(Integer(42))
Multiple: Multiple([String("hello"), Integer(123), Decimal(45.67)])
----------RON----------
Error: SpannedError { code: Message("data did not match any variant of untagged enum WrapperStruct"), span: Span { start: Position { line: 1, col: 15 }, end: Position { line: 1, col: 16 } } }

---

With serde version 1.0.225 :

[package]
name = "bug_serde"
version = "0.1.0"
edition = "2024"

[dependencies]
ron = "0.11.0"
serde = { version = "1.0.225", features = ["derive"] }
serde_json = "1.0.145"

----------JSON----------
Single: Single(String("hello"))
Integer: Single(Integer(42))
Multiple: Multiple([String("hello"), Integer(123), Decimal(45.67)])
----------RON----------
Error: SpannedError { code: Message("data did not match any variant of untagged enum WrapperStruct"), span: Span { start: Position { line: 1, col: 15 }, end: Position { line: 1, col: 16 } } }

So the bug has appeared since version 1.0.220

Now have to pin the old version in Cargo.toml.

serde = { version = "=1.0.219", features = ["derive"] }

Thank you in advance for your help.

[juntyr]

This is likely a duplicate of #581, which will be fixed by #582

[rxdiscovery]

I saw the fix, so it’s the relocation of __private::content::Content into serde_core that caused this bug.

I have a suggestion for automatically detecting this kind of change: why not add a dummy piece of code that uses serde_core::__private::content::Content ? That way, if there’s any change in Serde that alters the module structure, the code won’t compile, allowing the problem to be detected quickly.

[juntyr]

We do have tests that check that our hacky approach works, and CI caught the issue around the same time as users did. Making it into a hard error would be possible but, since we are relying on private implementation details of serde that can be changed at any time, that may cause serious problems. I'm still hoping that serde fixes the longer-term issue so that we no longer have to rely on its internal details

[rxdiscovery]

So it would be necessary to check with the Serde team, and perhaps integrate this function directly into serde_core, for example.

    fn is_serde_content<T>() -> bool {
        matches!(
            core::any::type_name::<T>(),
            "serde::__private::de::content::Content"
                | "serde::__private::de::content::Content<'_>"
                | "serde_core::__private::content::Content"
                | "serde_core::__private::content::Content<'_>"
        )
    }

[juntyr]

With serde-rs/serde#2980 serde has unfortunately made it near impossible to even fix this issue. So for now pinning serde <1.0.220 may be necessary. I'm sorry about that.

[konstin]

Does this mean you do not expect that #[serde(untagged)] can be fixed in ron?

[juntyr]

#582 could at least get us back to the status quo (I've unfortunately not had the time to push the PR over the finish line). A proper fix, as always, depends on serde supporting custom buffer types.

[rxdiscovery]

Thank you for the tremendous effort you put into maintaining this amazing crate. Maybe it’s asking a bit much, but could you consider implementing a temporary — even static — solution while we wait to see what the serde team decides?