Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No_std support #516

Closed
wants to merge 14 commits into from
Closed

No_std support #516

wants to merge 14 commits into from

Conversation

r-marques
Copy link

@r-marques r-marques commented Feb 1, 2019

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 dtolnay added the wip label Feb 2, 2019
@dtolnay dtolnay changed the title WIP: Experimental no_std support No_std support Feb 2, 2019
@dtolnay
Copy link
Member

@dtolnay dtolnay commented Feb 2, 2019

Thanks, looks like this is in the right direction.

r-marques added 4 commits Feb 6, 2019
- ryu is no longer optional since it supports no_std by default
- added itoa with default-features disabled for no_std
- re-exported to_* methods in the root
@r-marques
Copy link
Author

@r-marques r-marques commented Feb 6, 2019

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
Copy link

@gbip gbip commented Apr 17, 2019

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

@r-marques
Copy link
Author

@r-marques r-marques commented Apr 17, 2019

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
Copy link

@gbip gbip commented Apr 17, 2019

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

@r-marques
Copy link
Author

@r-marques r-marques commented Apr 17, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants