Support no_std compilation for various crates

[james7132]

trafficstars

Objective

Partially addresses #6370. Make many of the crates no_std.

Solution

Replace std with core and alloc.

Also sprinkles a few forbid(unsafe_code) where it's trivial to add it to a crate.

This does not guarantee all of these crates will build for no_std environments. Many still have dependencies with std deps.

[james7132]

Going to assume this controversial by default due to the commitment and potential maintenance burden this may have.

[mockersf]

This does not guarantee all of these crates will build for no_std environments. Many still have dependencies with std deps.

Are at least a few of the crates no_std compatibles with this? Would it makes sense to add that check to CI for those / how long would it take?

[james7132]

Quite a few of them are. The few that aren't usually require some kind of IO, since std::fs and std::net have zero core or alloc equivalents. Assets in particular may need to split between the type and ECS definitions and the actual IO implementation.

By specifying a crate being no_std, it already doesn't load the stdlib while compiling, so I don't think we need a CI job to check this until we have no_std enabled for the entire engine.

[james7132]

Another major blocker I'm running into: thiserror has zero support for no_std. We could manually implement it, or find another no_std compatible error derive crate.

[jfaz1]

Any chance we could split this PR up and extract some of the easier-but-essential crates that are compatible with no_std? I think most users wanting to use no_std right now are probably plugging in bevy_ecs and maybe bevy_transform/bevy_hierarchy into a separate ecosystem (e.g. Godot). In my case I'm working on a small side project for PlayDate and all I'd really be able to plug in are those three (though all I really need is bevy_ecs.) I'm using HECS for the time being and it's working great but I'd like to use Bevy since that's what I'm using for my main project.

[alice-i-cecile]

I'm happy to review any smaller forms of this PR: breaking it up by chunks seems very appealing.

[cart]

Its worth exploring + discussing what the bounds should be for this. no_std is limiting and less documented/familiar/standard. Is a full port / hard no_std requirement viable? What ecosystem crates would we be leaving behind? If a full port isn't viable, how targeted should we be? What crates yield the most fruit cost-benefit-wise (ex: bevy_ecs comes up the most regularly). Should we port examples if we know a full port isn't viable?

[james7132]

The primary things that we'd be missing are, as far as I know:

• std::thread and std::sync. These come up for parallelization and concurrency, but we already have ways of disabling threading. We may need to drop down to lock_api to find alternatives for the latter.
• std::io is the other big one, which precludes a large portion of the asset-dependent crates. Thankfully we haven't started adding networking capabilities to first party crates yet other than in-browser fetches, but std::net would be another potential area that'd be impacted.
• Platform integration crates (winit, wgpu, gilrs, etc) are platform specific and they'll need to be extended on a per-platform basis. Thankfully, bevy_window and bevy_input are operating as abstraction points, so they too could be ported over, and a separate platform integration for those could work. However, the tight coupling for bevy_render and wgpu means a subset of rendering will likely need to be carved out (i.e. the bevy-only types) to allow for swapping out wgpu on another platforms, or wgpu will need to be extended for that platform's support.

alloc is probably the biggest thing we cannot get rid of, and I don't think it makes sense to be running Bevy on a platform without heap memory allocation of any kind.

This likely precludes most of the engine given our dependencies on many of these parts.