Support no_std

[dtolnay]

We have been putting this off because nobody has needed it so far.

But in dtolnay/dtoa#8:

<pierre-rouanet> I'm currently trying to use serde_json on a microcontroller

[japaric]

FWIW, this morning I wrote a serde-json-core crate that provides JSON (de)serialization on no_std. It's certainly not on par with the real serde-json as I don't plan to add any stuff that requires dynamic memory allocation to it, or add support for floats. I also made some adjustments to avoid having the binary size of my firmware increase by several KBs. Anyway, you can check the documentation for details about what works and what doesn't work.

Also, I don't plan to send a PR to serde-json as I doubt all my changes are going to be welcomed, but anyone else is free to try.

cc @pierre-rouanet @perlindgren @MrBuddyCasino

[dtolnay]

Nice! I am happy to have @japaric own a separate no_std JSON library. The API is sufficiently different that I think both std and no_std users will be better served if we keep these as separate libraries. I have retagged this issue as a docs issue to drop a link to serde-json-core in our readme and rustdoc.

[dtolnay]

I added a link to serde-json-core in our readme and rustdoc, as well as https://serde.rs/no-std.html. Thanks!

[dtolnay]

Reopening because there continues not to be a no_std JSON crate that can support types from alloc (String, Vec). rust-embedded-community/serde-json-core#4
I would be willing to consider a PR that adds a std feature on by default, and exposes the same or a subset of the current API of serde_json by using the alloc crate in no_std mode.

[geofft]

I gave this a shot for fishinabarrel/linux-kernel-module-rust because we support allocation just fine, and serde-json-core doesn't support either dynamic types (like serializing/deserializing a Vec) or nifty things like JSON Pointer. (Also the "heapless" stuff, while it sounds fantastic for environments that need it, is frustratingly unergonomic for environments where normal vectors and strings work.)

Unfortunately it looks like the bulk of src/ser.rs is implemented via the std::io::Write trait, and even serialization to a string relies on impl Write for Vec<u8> and casting that to a string, and std::io isn't available in a standalone crate.

A couple of options that occur to me:

• Rewrite this support to not rely on Write.
• Use an alternative std::io-like crate which can map to both std::io and no-std environments, like https://crates.io/crates/genio (I'm not sure what the state of the art is here).
• Lobby the Rust developers to spin out std::io into its own stable crate the way alloc is its own crate.
• Give up on making no-std work for this use case and figure out how to build std in a minimal way for freestanding environments, by returning an error for all the things that actually need OS interfaces but letting traits and in-memory stuff work.

I'm leaning towards the last option n fishinabarrel/linux-kernel-module-rust#121, but that's pretty involved.... but if other people are interested in that approach, then it would make more sense to go down that road. (Also, because of issues with build-dependencies and no-std described in that ticket, we probably couldn't use serde-json even if there were a working no-std version, until that Cargo bug gets fixed too.)

[Xanewok]

This should be addressed by #606 now (I'm sorry, I forgot to add a relevant Closes directive in the PR)

[geofft]

Wow, thank you @Xanewok! I'm excited to try it out!