Make no-std compatible

[stargazing-dino]

After reading the bevy 0.16 release, I'm very excited for no-std. I'd love to see this package also head in that direction

I've had a quick look around the codebase and would likely do:

1. Core migration

• Add std feature flag (enabled by default)
• Replace all usages of std and replace with core alternatives
• Conditional imports for some imports:

// I think this is how they do it?
#[cfg(feature = "std")]
use std::collections::HashMap;
#[cfg(not(feature = "std"))]
use alloc::collections::HashMap;

For dependencies:

Dependency	no-std compatible
prost	✔️
serde	✔️
bevy	✔️
variadics_please	✔️

2. Runtime migration

• Add std feature flag (enabled by default)
• Replace all usages of std and replace with core alternatives
• Allow for platform-agnostic alternatives:

Dependency	no-std compatible
unicode-normalization	✔️
unicode-segmentation	✔️
bevy	✔️
variadics_please	✔️
log	?
icu_plurals	✔️
icu_locid	✔️
fixed_decimal	✔️
once_cell	✔️
regex	✔️
serde	✔️

3. Compiler

I guess the compiler could stay std. Not sure really. antlr-rust last update was 3 years ago, but its usages of std also don't seem super platform dependent.

The last consideration would be to get some tests up and early. Bevy has some that build to wasm targets which should be feasible to adapt.

[janhohenheim]

Awesome idea! @bushrat011899 maybe you are also interested in this, as our resident no_std rat :)
As for ANTLR-Rust, I have no problem replacing that with a no_std compatible fork.

[stargazing-dino]

So here's a question. Following #238 there will be these calls to std still:

Most of them are collection types we can quickly swap to hashbrown. The tricky ones are the RwLock and Arc. Their alternatives are highly dependent on target platform i think.

The shortcut I'm proposing is that we offload finding a suitable replacement and instead unconditionally rely on bevy_platform and their implementations of RwLock and Arc - which I think uses a spinlock under the hood.

Thoughts?

[bushrat011899]

I would definitely recommend using bevy_platform for these kind of things. When bevy_platform/std is enabled, you're just using std and whatever alternatives Bevy has already determined better suit the engine (e.g., Hashbrown for performance reasons, etc.). It'll also handle things like portable-atomic for you on atomically challenged platforms too.

[bushrat011899]

Also, the regex crate is no_std compatible, just need to disable default features and re-enable the ones you need.

[janhohenheim]

@bushrat011899 is bevy_platform also suitable for crates that don't depend on Bevy? As in, I suppose its slim, self-contained and doesn't pull in other Bevy stuff, right?
Asking because our underlying crates support no-bevy workflows.
If so, then we should add a comment above the dependency saying that even though this says "bevy" on the tin, it's general purpose and is not pulling in much :)

[bushrat011899]

@janhohenheim Yeah it's definitely suitable for non-Bevy usecases. The only Bevy-specific part of it (aside from the name obviously) is the idea that the Bevy project chooses what it considers an acceptable replacement for std items. So using spin for RwLock as an example makes sense for Bevy, since the only no_std support it has (currently) is for single-threaded, where spinning won't actually happen anyway.

But, if there are concerns around relying on it, you could definitely just read the bevy_platform source and take the couple of shims you need.

[janhohenheim]

That's good enough for me then :) @stargazing-dino let's use bevy_platform with a little disclaimer comment

[stargazing-dino]

When bevy_platform/std is enabled, you're just using std

Is this to say that swapping to bevy_platform collection types will still let std consumers use std collection types? I'm running into an issue where I'm seeing:

`HashMap<String, String, _>` and `HashMap<String, String>` have similar names, but are actually distinct types

Or I guess how do you recommend we expose the external API to users?

[stargazing-dino]

Alright, so last two I think are bevy_yarn_plugin and compiler.

bevy_yarn_plugin is tricky. It already has stuff in place to handle platforms with limited filesystems (like wasm) which is good. However it directly relies on bevy with the feature bevy_asset. This kinda forces std if I understand it correctly.

This leaves maybe the compiler. It'd require a fork of antlr (which I don't think would be the worst) to make it no-std. Another consideration would be annotate-snippets which is under rust-lang umbrella but currently assumes std. That's used for diagnostics so perhaps it could be put behind a feature flag?

Another i wouldn't know how to handle would be better_any. I'm not sure how it's used in the codebase currently.

For the compiler, I'm assuming we'd need some trait-based abstraction for file access. Really not sure on any of this, but if anyone has guidance I'd be happy to hear it.

[janhohenheim]

IIRC better_any is heavily used by ANTLR, so that might be a challenge