Add no_std Support

[bushrat011899]

Objective

I'm working on no_std support for several crates across the Rust ecosystem, and was surprised to see ron is one such crate! Having such support would be helpful for the Bevy game engine, as we use ron for metadata files. Porting our asset systems to no_std will require ron to be no_std as a prerequisite.

Solution

• Added std feature. std enables the usage of the std crate.
• Adjusted the SERDE_FLATTEN_CANARY test in src/de/mod.rs to use a String rather than a byte array. This may require more investigation. I believe my fix is correct, but may over-allocate.
• Added alloc_instead_of_core, std_instead_of_alloc, and std_instead_of_core lints to help with maintaining no_std support.
• Feature gated methods relying on std::io behind std.
• Switched to a BTreeMap as the inner map for the Fields type when std is not active. This may not need to be feature gated and could be used in both circumstances, but I have not tested to confirm a BTreeMap is equivalently performant.
• Updated the usage of IndexMap to explicitly use the std RandomState to highlight how the indexmap feature could be made no_std in the future (requires including an alternative hasher).
• Adjusted imports to refer to core and alloc where required.
• Removed std features from dependencies.
• The f32::fract andf64::fract methods are not available in no_std. However, they can be accessed using x % 1. instead.
• Import std::error::Error from serde::ser::StdError. serde uses a build.rs script to work out whether it can use std, core, or if it must define its own Error trait, and publicly exports it. We can use that instead of needing to determine core vs std ourselves.

Notes

• This is my first time contributing to this project, please let me know if there's anything I can do to help!
• I've included my change in CHANGELOG.md

[juntyr]

Thank you for working on this feature!

I think the next step would be to fix CI by ensuring only the right feature combinations are tested. In particular, the core error feature should be run with the 1.77.

[bushrat011899]

Damn, thought I'd caught all the CI issues already. I'll do another pass tonight and try and fix those issues too.

[juntyr]

As you might see, clippy on >1.64 flags lots of things that we cannot use on 1.64. So while you're free to fix some of them, we only run clippy on the MSRV for this reason

[bushrat011899]

Ok looks like it's just an issue with serde and core::error::Error I need to diagnose.

[juntyr]

Nit: could the CI matrix case names be changed so that instead of e.g. false, true, false, true we'd see the features used?

[bushrat011899]

Nit: could the CI matrix case names be changed so that instead of e.g. false, true, false, true we'd see the features used?

I'd love to do that. I think it's controlled by run-name, but I'll need to experiment to confirm (GitHub Actions are still pretty new to me!)

[bushrat011899]

Ok I think the Check tasks should have pretty names now, and the errors found in fuzzing and testing should be resolved (both require either the std or core_error features)

[bushrat011899]

Ok the last CI failure was very informative, and I've been able to remove that core_error feature, since serde publicly re-exports StdError for us, going through the trouble of managing MSRV and no_std requirements using build.rs. I've updated tests and examples as well, but refer to the individual commits to see the tests still cover the same content (just minor refactoring).

[juntyr]

Thanks @bushrat011899 for all of your work on this!

I was wondering, now that the feature matrix is simpler again, if we could use cargo hack instead of a GitHub matrix to make use of caching and not spawn so many jobs.

[juntyr]

Thanks @bushrat011899 for all of your work on this!

I was wondering, now that the feature matrix is simpler again, if we could use cargo hack instead of a GitHub matrix to make use of caching and not spawn so many jobs.

Ping @bushrat011899

[bushrat011899]

I was wondering, now that the feature matrix is simpler again, if we could use cargo hack instead of a GitHub matrix to make use of caching and not spawn so many jobs.

Sorry about the delayed response! Got distracted and forgot to come back to this, thanks for the ping! I've updated the CI task to use cargo-hack and remove the somewhat sketchy feature flag matrix stuff. Should be faster and easier to test locally too!

[juntyr]

Thanks @bushrat011899! Finally, could you also write the CHANGELOG entry and then I'll merge your PR :)

[bushrat011899]

Thanks @bushrat011899! Finally, could you also write the CHANGELOG entry and then I'll merge your PR :)

Done! I've listed it as a breaking change, but it technically isn't since nothing has changed when default features are enabled. I explicitly included all items which are now gated behind std just to make migration as easy as possible, but it's pretty obvious what's missing (things that use std::io in their public API).

[juntyr]

Thank you so much @bushrat011899 for all the work you put into this PR <3