Code is broken for wasm32-unknow-emscripten

[caiiiycuk]

When I try to build project that depends on [email protected] for target wasm32-unknow-emscripten, I have lot of messages like this:

  --> /home/caiiiycuk/.cargo/registry/src/github.looper.workers.dev-1ecc6299db9ec823/ron-0.7.0/src/de/id.rs:74:5
   |
74 | /     fn deserialize_i128<V>(self, _: V) -> Result<V::Value>
75 | |     where
76 | |         V: Visitor<'b>,
77 | |     {
78 | |         unimplemented!("IdDeserializer may only be used for identifiers")
79 | |     }
   | |_____^ not a member of trait `de::Deserializer`

I believe it's because emscripten target does not have i128/u182 types. Serde in that case does not have deserialize_i128/u128. As workaround I use version 0.5.1, it does not contains i128/u128 and works fine. However I would like to update to latest version if possible.

[juntyr]

Related to #304

[juntyr]

I've done a tiny bit of investigation. As serde only provides serde_if_integer128 but no else variant, I did not find a way to tap into just serde to e.g. change the definition of

ron/src/parse.rs

Lines 89 to 103 in 7fefc00

	#[derive(Clone, Debug, PartialEq)]
	pub enum AnyNum {
	F32(f32),
	F64(f64),
	I8(i8),
	U8(u8),
	I16(i16),
	U16(u16),
	I32(i32),
	U32(u32),
	I64(i64),
	U64(u64),
	I128(i128),
	U128(u128),
	}

. So I think #[cfg()]s are needed. While ron could mirror part of serde's build script, this does seem overkill. Adding a separate integer128 feature as suggested in #304 seems like the better option. This could then be tested by trying to build with target wasm32-unknown-emscripten on 1.36.0. Or ron could bump its MSRV to 1.40 which is when emscripten gained support for 128b integers. @caiiiycuk what Rust version are you using?

[caiiiycuk]

1.53.0

[torkleyy]

I think adding wasm to the build matrix makes sense. @kvark thoughts on this? I think a feature for integer128 would make sense, most of the time you don't need i128 anyways IMO. I see that features increase the complexity when it comes to testing and build scripts but this seems like a good reason.

[kvark]

Yes, it all sounds reasonable. Although, I think @caiiiycuk 's original need for this issue is no longer active, if I understand correctly. This was needed for vange-rs, and the current plan is to use wasm32-unknown-unknown instead.

[caiiiycuk]

Correct, but I think for consistency should be fixed at some time.
+1 for adding feature

[juntyr]

@caiiiycuk Has this been fixed with #351?

[caiiiycuk]

Just checked on vange-rs, works like a charm!