modular-bitfield
modular-bitfield copied to clipboard
Robbepop
Macro to generate bitfields for structs that allow for modular use of enums.
Currently the getters and setters generated by the `#[bitfield]` proc. macro for its bitfield struct are not `const fn`. This is because they are making heavy use of functionality that...
I started getting a new Clippy lint, [`return_self_not_must_use`](https://rust-lang.github.io/rust-clippy/master/index.html#return_self_not_must_use), when I updated my nightly compiler. This appears to be a simple fix of adding `#[must_use]` to the `with_*` methods created by...
Adding `repr` to the struct results in a clippy warning: ``` the operation is ineffective. Consider reducing it to `mregion: u8` ``` Adding `#[allow(clippy::identity_op)]` on top of the struct does...
Fixes https://github.com/Robbepop/modular-bitfield/issues/62
Currently the easiest way to serialize/deserialize modular-bitfields using serde is by converting to/from another struct when serializing/deserializing. Ideally this could be handled automatically by modular-bitfield similarly to Debug impls (see...
It would be cool if bitfield loads and stores could also be atomic. For example, it is very usable in GC systems where object color might be encoded in 2...
Currently calling `into_bytes()` consumes the object, but it would be nice to have access to the bytes via a reference or mutable reference.
It would be helpful to have a constant on each bitfield struct that indicates its length, for example ```rust #[bitfield] pub struct MyFourBytes { a: B1, b: B3, c: B4,...
I'm currently using modular-bitfield for a project and am incurring in warnings generated by the the crate. When a bitfield structure is annotated with a [`repr` representation](https://docs.rs/modular-bitfield/0.11.2/modular_bitfield/attr.bitfield.html#support-reprun), the generated code...
For `repr(uN)` bitfields, it'd be helpful to be able to view a reference to the bitfield as a reference to the representation type without copy. The opposite is also true...
