Fix no_std support for Copy bitflag and others

[Eisverygoodletter]

The current version of #[bitflag] emits #[derive(std::marker::Copy, core::clone::Clone)] which will fail if building from no_std. I've changed this and a few other instances of std references to core and alloc so that the macros will work on no_std.

The Cargo.toml currently pins a specific nightly version (1.95) which has been released now. Should that be changed?

[codecov]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

[Eisverygoodletter]

Seems like since alloc needs to be explicitly imported the std -> alloc changes would be breaking. I'll revert the changes to alloc to make this a non breaking change for now. Purely no-std targets that don't need the alloc or boxing features should work with this.

[gregorygaines]

Thanks for finding this, let me take a look!

[Eisverygoodletter]

no_std + alloc support should probably be added separately because the implementation will probably need to add a new std feature flag and probably be a semver breaking change.

[gregorygaines]

Let me see where alloc is being used in the code, ideally we should not rely on std at all.

[Eisverygoodletter]

The array_heap = true generation requires boxes. By default on std targets, alloc is hidden and std re-exports its contents, but on no_std targets, both are unavailable until you do extern crate alloc, so it's a bit awkward because if you do ::alloc::... then it would only work on no_std targets with alloc and if you do ::std::... it would only work on std targets but not the other one.

[gregorygaines]

Got it! So how about this, we have an array_heap_std and an array_heap_no_std flag that covers each respective case and generates the appropriate code?

[gregorygaines]

As for The Cargo.toml currently pins a specific nightly version (1.95) which has been released now. Should that be changed? What do you propose be done?

[Eisverygoodletter]

Change it to
channel = "1.95.0"

[gregorygaines]

Cool, so we can go ahead and merge your change and I'll follow up:

1. Update array heap flags and code generation.
2. Update channel to 1.95.0
3. Update no-std tests so issues like this are caught.

Sound like a plan?

[Eisverygoodletter]

I assume the change to array_heap feature flags would be a semver breaking change since disable_array_heap would have to be deleted? Currently the contents of this PR (just the changes to Copy) aren't breaking and can fall under a new version only bumping the patch version number so the downstream crates can get this fix automatically.

[gregorygaines]

Yes, I would make the array_heap feature a breaking change. And yes, this can be version v2.0.9.

[Eisverygoodletter]

Yes, that should work. Thanks for the quick responses!