Avoid using `std` dependency about enumflags

[MaikKlein]

I pushed the changes to https://github.com/MaikKlein/enumflags/tree/no_std

You can use it like this

enumflags_derive = {path = "../enumflags_derive", default-features=false}

I want to test it a bit more before I merge it with master.

[MaikKlein]

@aoowweenn Sorry for the delay, I refactored almost everything. The println should be gone now.

[MaikKlein]

I myself don't do embedded programming but I guess there shouldn't a problem with switching from std to core. I'll look into it tomorrow.

[MaikKlein]

I currently use a vector for the debug output https://github.com/MaikKlein/enumflags/blob/master/enumflags_derive/src/lib.rs#L229

I also want to generalize that behavior so that you can create a flag from a vector of flags, and that you can create a vector of flags from a single flag. I do this to generate a better debug output, eg BitFlags { 0b1111, Flags::[A, B, C, D] }. But this is quite unnecessary for the debug output, it should be possible to avoid the heap usage here by directly writing to the fmt instead of collecting into a vector.

I think that it should be possible to feature gate the std usage.

[jmi2k]

I took care of removing std-dependent code in my fork, but I need your help with some things:

• At enumflags_derive/src/lib.rs:100 extern crate core is needed. But if I add it, enumflags breaks when using std. Please take a look at it.
• At enumflags_derive/src/lib.rs:168, I commented that println!. Really, I don't know why it's there, but I prefer leaving it until I get your opinion.
• At enumflags_derive/src/lib.rs:237 there is a function that isn't documented anywhere, but returns a Vec and prevent it from being used without std.

I think these changes are enough. I'll make a (new) PR if I make it work...

[MaikKlein]

1. and 3.: It probably breaks because I still rely on the std. I didn't realize that I already had implemented from_bitflag. This is useful if you ever want to use enumflags in a config file. For example

[Input.Jump]
Key = Left
Modifiers = [Shift, Ctrl] // <- enumflags

Which means I need a way to convert from a list of flags into a BitFlags<Flag> and the other way around, this is essentially what ``from_bitflag` is currently for.

I think we should just feature gate the std usage like here https://github.com/BurntSushi/byteorder/blob/master/src/lib.rs#L53

#[cfg(feature = "std")]
pub fn from_bitflag(bitflag: ::enumflags::BitFlags<#ident>) -> Vec<#ident> {

2. This is something that shouldn't be there.

I really need to add some documentation and tests.

[MaikKlein]

Regarding extern crate core. I implement something called

pub struct #inner_name(#ty); which is the inner type of the bitflag. This is necessary because it is not possible to implement code between two crates (enumflags and enumflags_derive are two separate crates).

Currently this inner type is in user space, which seems to cause problems with core. I am not completely sure what the best cause of action would be.

The problem here is that because the inner_type is in user space which errors if the user doesn't have extern crate core. One solution would be do implement the inner_type two times for core and std, and then feature gate the implementation.

        impl #std::fmt::Debug for #inner_name{
            ...
        } 

where #std could be ::std or ::core. Otherwise I could try to find a different solution that doesn't require the inner type at all.

[MaikKlein]

Actually the bitflags create also creates everything in user space(macros) and it doesn't require the std. https://doc.rust-lang.org/bitflags/src/bitflags/lib.rs.html#250-286

I'll look into it. Sorry for the back and forth, I haven't really done anything without the std.

[MaikKlein]

The trick here is

#[allow(private_in_public)]
#[doc(hidden)]
pub use core as __core;

And then use ::__core instead of ::core. This solves your 1.

[jmi2k]

I think we can't do that because it uses no_std itself. It cannot be used in enumflags_derive because we are using some std features for code generation, even if they don't show up in the final code.

Look at my last commit, I resolved the issue with a feature. The only problem left is from_bitflag, which honestly I have no idea of what to do. I've never used quote! nor procedural macros though.

[MaikKlein]

I don't meant that we should use it inside enumflags_derive but in enumflags. Then you can access it like this (because it is just a public re-export).

let i = enumflags::__core::option::Option::Some(42);

Which means that we can do something like this inside enumflags_derive.

        impl enumflags::__core::ops::BitOr for #inner_name{
            type Output = Self;
            fn bitor(self, other: Self) -> Self{
                #inner_name(self.0 | other.0)
            }
        }

I got it working with the first version of your fork. Or at least it appears to be working. Do you want me to push the changes?

[jmi2k]

Go ahead 👍 !

[jmi2k]

I replaced bitflags with it and it works perfect!

[jmi2k]

Sorry, I think it's better to keep it open until it's merged.

[aoowweenn]

Any progress here?
I just don't want println! appeared in from_bits.
Thx

[MaikKlein]

Should be fixed in the latest released