Investigate no_std, improve core / std consistency

[chitoyuu]

From this discussion in a PR: #1026 (comment)

It's mostly a matter of consistency and surprise factor -- when I see core::, my association is immediately no_std, but maybe the Rust community sees this differently, and using core when it suffices is good practice.

Most of the codebase currently uses std:: though, with a handful of core:: occurrences for things like core::cmp::Ord, core::marker::PhantomData -- but even those are not used consistently. It's only a cosmetic issue though.

While no_std should be irrelevant for all the main, openly available targets, it might be slightly relevant for consoles or other obscure platforms. If the cost to support it is reasonably low, it should be a nice-to-have.

Otherwise, we can change all imports from core to std for consistency.

[necrashter]

Will this affect the build size, especially for web? #1021 requires a smaller debug build size.

[chitoyuu]

Theoretically it should reduce the build size slightly if possible, since the extra part of std outside core and alloc will no longer have to be linked. Keep in mind that this is supposing the rest of your application is fully no_std.

In reality I don't think the impact would be as big as doing something about the from_raw function.

[wg-romank]

I actually have a use-case for deriving ToVariant and FromVariant traits on types that are packaged with no_std. I use Godot as an interactive UI to talk to microcontroller and having a single crate to share data structures would be huge boon.

I am not very familiar with proc-macros so if someone could give me pointers that would be great.

I understand it is quite niche use-case, so sorry if off-topic and thanks.

[Bromeon]

@wg-romank that sounds very interesting! Could you elaborate the architecture you are using a bit?

Even if the ToVariant/FromVariant traits had some impls for no_std types, most of the gdnative crate would probably still require the standard library. And due to orphan rule, we cannot split trait definition from impls (e.g. for Vec<T> which uses allocation). The only thing I could imagine is a feature flag that disables (or enables because additive) 95% of gdnative, leaving only no_std types.

Maybe I'm missing something, I don't have much experience with Rust and no_std environments. How would you imagine this?

[wg-romank]

@Bromeon it is all in very WIP stage and Godot part is underdeveloped at the moment but I have it all in this repo https://github.com/wg-romank/quad

Basically I have a shared crate (common) that defines ADT for message format to be sent over the wire and I share that message type between crate that targets no_std and utils library that I compile with gdnative.

Currently I just export bunch of methods for respective message types with gdnative which works but I need to write a bit of boilerplate.

I tried to define feature for common crate and use #cfg_attr rules for conditional compilation so when I target no_std it does not include gdnative dependency. Here are exact details to be more specific

Afaik derived ToVariant implementation does not require std at least it does not seem to complain when I add derive clause to my shared crate. So all is missing is to get FromVariant to work the same.

I am also not sure why it complains since derive is conditional, maybe it all is just misconfiguration, but I get a following error.

error[E0433]: failed to resolve: could not find `std` in the list of imported crates
  --> common/src/lib.rs:79:68
   |
79 | #[cfg_attr(feature = "godot", derive(gdnative::prelude::ToVariant, gdnative::prelude::FromVariant))]
   |                                                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ could not find `std` in the list of imported crates
   |
   = note: this error originates in the derive macro `gdnative::prelude::FromVariant` (in Nightly builds, run with -Z macro-backtrace for more info)

Overall it is just a convenience thing to get message types pass Godot boundary, and Rust bindings for Godot work great, so thanks a lot for putting them together and sorry for a long post.

[wg-romank]

Silly me, I had unconditional no_std at the top of the crate and that made the error pop up. Please disregard my message it works with this approach. Apologies for diverting discussion.