#[serde(alias = "somename")] stopped working after 0.6

[VegarRingdalAibel]

After when going from 0.5 to 0.6 it looks like alias is broken

Using:

wasm-bindgen = "0.2.91"
serde = { version = "1.0.196", features = ["derive"] }
serde_json = "1.0.113"
serde-wasm-bindgen = "0.6.3" //0.5 works... fails if i go higher
console_error_panic_hook="0.1.7"

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum FilterAction {
    Append,
    Remove,
    Keep,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum FilterType {
    Standard,
    Boundingbox,
}

#[derive(Debug, Serialize, Deserialize, Clone)]
pub struct FilterInput {
    #[serde(alias = "filtertype")]
    pub filter_action: FilterAction,
    #[serde(alias = "type")]
    pub filter_type: FilterType,
    ...

This is my input

get error:

panicked at src\lib.rs:228:58:
called `Result::unwrap()` on an `Err` value: Error(JsValue(Error: unknown variant `Append`, expected `Standard` or `Boundingbox`
Error: unknown variant `Append`, expected `Standard` or `Boundingbox`

Its like its setting values from json filtertype to rust filter_type when it should have used json type.

Is it a bug or have I just been lucky it been working ?

[RReverser]

Hm... the last change that transitioned from 0.5 to 0.6 was #40, but I don't see why it would cause this particular breakage.

[RReverser]

To be clear, does it break on transition to any 0.6 or only 0.6.3? Did you try pinning exact versions so that Cargo doesn't fetch the latest 0.6.x? That might help tracking it down further.

Alternatively, you can do git bisect on this repo and add it as a path dependency in Cargo.toml.

[VegarRingdalAibel]

I'll do a new try later this week, so I know better when it breaks. I can try and create a simple sample repo with the bug. 👍

[VegarRingdalAibel]

@RReverser Made a small sample containing 0.5.0(wasm1) and 0.6.0 (wasm2)

https://github.com/vegarringdal/wasm_test

[RReverser]

You can see from the Cargo.lock that wasm2 is not 0.6.0 but 0.6.3: https://github.com/vegarringdal/wasm_test/blob/9238388d3217b95fd3cd86bc4a6598c05af72c63/wasm2/Cargo.lock#L87-L89

That's what I suspected and why I mentioned pinning exact version to narrow it down further. I believe you can do that by specifying version as =0.6.0 instead of 0.6.0.

[VegarRingdalAibel]

Ill have a new look, though it would use the version I had here https://github.com/vegarringdal/wasm_test/blob/9238388d3217b95fd3cd86bc4a6598c05af72c63/wasm2/Cargo.toml#L14

[RReverser]

Yeah, no, Cargo auto-updates the version to whatever is compatible according to semver. It's usually the right choice, but not very helpful when debugging an issue.

[VegarRingdalAibel]

I have clearly missed this part 😂

[VegarRingdalAibel]

Error is after version 0.6.2, update repo

[RReverser]

Error is after version 0.6.2, update repo

What do you mean by "update repo"? Looks like you didn't push any new changes?

[RReverser]

That said, if it's 0.6.2+ rather than after 0.6.2 (0.6.3+), then I suspect it might be due to this change https://github.com/RReverser/serde-wasm-bindgen/commit/ce7669e1d175d999a733497e87152f55808ee8f2

Not sure if Serde supports field indices in combination with aliases.

[VegarRingdalAibel]

HI I pushed this change :-)

https://github.com/vegarringdal/wasm_test/commit/0b2fa8a8e28f78150b2a2737fe3c6785164d2241

That said, if it's 0.6.2+ rather than after 0.6.2 (0.6.3+), then I suspect it might be due to this change > > https://github.com/RReverser/serde-wasm-bindgen/commit/ce7669e1d175d999a733497e87152f55808ee8f2

Not sure if Serde supports field indices in combination with aliases.

I dont know :-)

[RReverser]

Yup, looking at generated code from serde::Deserialize, the indices it expects don't match the order of fields:

                const FIELDS: &'static [&'static str] =
                    &["filter_action", "filtertype", "filter_type", "type"];

...


                    fn visit_u64<__E>(self, __value: u64)
                        -> _serde::__private::Result<Self::Value, __E> where
                        __E: _serde::de::Error {
                        match __value {
                            0u64 => _serde::__private::Ok(__Field::__field0),
                            1u64 => _serde::__private::Ok(__Field::__field1),
                            _ => _serde::__private::Ok(__Field::__ignore),
                        }
                    }

...

                                __Field::__field0 => {
                                    if _serde::__private::Option::is_some(&__field0) {
                                            return _serde::__private::Err(<__A::Error as
                                                            _serde::de::Error>::duplicate_field("filter_action"));
                                        }
                                    __field0 =
                                        _serde::__private::Some(_serde::de::MapAccess::next_value::<u32>(&mut __map)?);
                                }
                                __Field::__field1 => {
                                    if _serde::__private::Option::is_some(&__field1) {
                                            return _serde::__private::Err(<__A::Error as
                                                            _serde::de::Error>::duplicate_field("filter_type"));
                                        }
                                    __field1 =
                                        _serde::__private::Some(_serde::de::MapAccess::next_value::<String>(&mut __map)?);
                                }
                                _ => {
                                    let _ =
                                        _serde::de::MapAccess::next_value::<_serde::de::IgnoredAny>(&mut __map)?;
                                }

That's pretty unfortunate. I don't think I can properly fix it without some fix on Serde's own side, so I'm just going to revert that optimisation for now :(

[RReverser]

Fixed in 0.6.4. Thanks for the report!

[VegarRingdalAibel]

Thank you.