No_std support

[r-marques]

Here be dragons

This is an attempt at resolving #362.

---

This pr is far from complete. The goal is to start a discussion on what the effort would be to correctly add no_std support to serde_json.

What was done so far:

• Added a std feature that is enabled by default
• Added a no_std feature so that we can enable specific dependencie features as required (e.g. alloc in serde)
• Added no_std support for the deserializer

Build with no_std:

cargo build --no-default-features --features no_std

# building for a different target
rustup target add thumbv7m-none-eabi
cargo build --no-default-features --features no_std --target thumbv7m-none-eabi

This was tested in another project were we use serde_json for json deserialization. We were able successfully compile with no_std support using the changes in this pr.

---

Problems:

The import logic can get messy:

• Nested imports makes it cleaner but they were only added in rust version 1.25
• We can probably try to reuse the import logic performed by serde. Although it's weird to depend on how another crate does imports

Requires nightly:

• Both serde unstable and alloc features require nightly

Cannot have dev-dependencies:

• There seems to be a problem in cargo where the dependencies and dev-dependecies features are unified. With the dev-dependecies I couldn't find a way to disable serde default features
• This also means that we cannot run the tests

Error handling becomes a bit more difficult, specially parts of the code that make heavy use of std::io::Error.

[dtolnay]

Thanks, looks like this is in the right direction.

[r-marques]

Just an update.

I added no_std support for the Serializer. For now I skipped the PrettyFormatter and the the raw_value and arbitrary_precision features.

My main concern now is to figure out a way to handle dev-dependencies (since it overrides the features) so that I can run the tests.

When you have the time let me know if you have any suggestions for the code so far.

[gbip]

Is there anything that could be done to help you finish this PR ? I have huge interest in this feature. 😄

[r-marques]

Right now the biggest problem is the fact that cargo unifies the dependecies and dev-dependecies which makes it difficult to run the tests. I don't really have a solution for that.

I would also need some input from @dtolnay to figure out how to proceed.

This merge request initially started from a previous project I was working on that was using serde_json. The project was using my fork of serde_json running on a cortex-m4f. In the meantime you can point cargo to my branch if you want to try it out.

[gbip]

Is your project running on a cortex-m4f open source ?
I could use some inspiration !

[r-marques]

Unfortunately the project although in a running state was abandoned and is currently closed source. I don't know at this point if the company will ever open source it.

But the rust embedded working group has great resources and the discovery book is actually using the cortex-m4f