modular-bitfield-impl
Derive macro for modular-bitfield
0.13.1
12M downloads/mo
#2828 most downloaded on crates.io
modular-bitfield/modular-bitfield
What this package is like to depend on
Last release 8 months ago
06 Dec 2025
Ships unpredictably
gaps range from 8 days to 4.5 years
Most releases are documented
notes for 10 of 16 stable releases
Nothing withdrawn
no release was ever pulled
7 years old
16 releases · first in 2019
2 releases in the last 12 months
see the full history below
Release timeline
16 releases · May 2019 to Dec 2025Releases
latest 16-
0.13.106 Dec 2025 -
0.13.019 Oct 2025Release notes
Open source →Breaking changes
- The MSRV is now 1.76. This is not currently a hard requirement of modular-bitfield itself but is instead the path of least resistance due to changes to underlying dev-dependencies, so please open a ticket if you really need support for an even older version of Rust.
From<[u8; {n}]>(when conversions are guaranteed) andTryFrom<[u8; {n}]>traits are now automatically derived by#[bitfield]. This will conflict with any manual implementations of the same trait, but you wrote those implementations to do this thing anyway, right? (#120)- The
BitfieldSpecifieralias, which was deprecated in v0.12, is removed.
Enhancements
- Diagnostic messages around invalid bit counts have been improved.
- Minor documentation improvements for the
Specifiertrait.
Bug fixes
-
0.12.005 May 2025Release notes
Open source →Breaking changes
- The MSRV is now 1.70. This is not currently a hard requirement of modular-bitfield itself but is instead the path of least resistance due to changes to underlying dev-dependencies, so please open a ticket if you really need support for an even older version of Rust.
- The
InvalidBitPattern::invalid_bytesfield is now private. Use theInvalidBitPattern::invalid_bytes()method to access the invalid bytes (andInvalidBitPattern::new()to create new errors).
Deprecations
- To conform with idiomatic Rust code, the derive macro
#[derive(BitfieldSpecifier)]has been renamed to#[derive(Specifier)]because it derives theSpecifiertrait. The deprecated alias will be removed in the next release of modular-bitfield.
Enhancements
- The syn dependency has been updated to version 2.
- Generated constructors and getters are now annotated with
#[must_use]. (#79) - Structs with const generics can now use
#[bitfield]. (#87)
Bug fixes
- Enumeration variant names will no longer conflict with code generated by
#[derive(Specifier)]. (#82) - Using
#[bitfield]on an empty struct now emits an appropriate diagnostic instead of causing a compile-time arithmetic error. (#104) - Various fixes to lints. (#62, #66, #93, #95. Thanks, @dimpolo, @diseraluca, @nilfit, and @LDVSOFT!)
- Various fixes to documentation formatting. (#91, #101, #103. Thanks, @00xc, @SebastianJL, and @jruderman!)
- When automatically deriving
Debug, tuple-like structs are now formatted normally instead of like structs with numeric fields.
-
0.11.207 Nov 2020Release notes
Open source →0.11.2 (2020-11-07)
- Fixed a bug that all but the first
#[skip(..)]attribute for a bitfield were ignored despite proper error handling.
E.g. when flagging a field with#[skip(getters)] #[skip(setters)]the#[skip(setters)]was ignored.
- Fixed a bug that all but the first
-
0.11.107 Nov 2020Release notes
Open source →0.11.1 (2020-11-07)
- Allow non-overlapping
#[skip(getters)]and#[skip(setters)]attributes. This might be useful for conditional compilation. - Fixed a bug with
#[skip]skipped fields not properly bumping the bit offset - Fixed a minor bug where duplicate
#[skip]attributes would yield a confusing error.
- Allow non-overlapping
-
0.11.006 Nov 2020Release notes
Open source →0.11.0 (2020-11-06)
- Add
bits: intparameter to the#[bitfield]macro which allows to precisely control the resulting bit width
of the generated bitfield struct. Use it like:#[bitfield(bits = 5)]. - Replace
#[bitfield(specifier = true)]syntax with#[bitfield] #[derive(BitfieldSpecifier)].
Semantics of the new syntax is the same as the old. - It is now possible to flag fields of
#[bitfield]structs with#[skip(..)]in order to skip code generation for them.
There are possibilities to skip code generation of only setters using#[skip(setters)], only getters#[skip(getters)]
or both. Having no arguments (e.g. just#[skip]) defaults to skipping both setters and getters.
A neat trick is to specify double wildcards as identifiers for skipped fields to avoid having the need to come up with
an identifier for them: For example:#[skip]: __: B10 - Attributes applied to
#[bitfield]fields are now properly propagated to their generated getters and setters.
Note thought that it might be confusing that an attribute applied to a struct field is actually applied to a function
through macro expansion. - Fixed several bugs and significantly improved error reporting for
#[bits = N]field attributes for#[bitfield]fields. - Minor fixes and improvements to code generation:
- The automatically implemented
#[derive(Debug)]now produces code that the Rust 2015 edition will accept. - Some minor macro hygiene improvements.
- The automatically implemented
- Add
-
0.10.029 Oct 2020Release notes
Open source →0.10.0 (2020-10-29)
- (Thanks @jam1garner): The
#[bitfield]macro now looks for#[derive(Debug)]annotations and if found will implement
one that formats the struct with its fields as a user would expect them. Previously having a#[derive(Debug)]
annotation on a#[bitfield]struct would simply print the contents of the generated internal byte array. - Implement
#[bitfield(bytes = N)]parameter to ensure at compile time that the bitfield struct
requiresNbytes of memory. - Implement
#[bitfield(filled: bool)]parameter to control whether the bitfield struct ensures that either
all bits are well defined (filled = true) or if there are going to be some bits intentionally undefined (filled = false).
The default isfilled = true. - Implement
#[repr(uN)]for#[bitfield]structs whereuNis one ofu8,u16,u32,u64oru128with which it is
possible to control whether a bitfield allow conversions betweenuNand the bitfield. Also it ensures at compile time that
the bitfield requires the exact same amount of bits. This is in conflict withfilled = false. - Bitfield structs are no longer implicitly
#[repr(transparent)]. If a user wants their bitfield struct to remain transparent
they have to add#[repr(transparent)]manually to their struct definition. - The default behaviour for
#[bitfield(specifier = bool)]got changed so that it no longer by default allows for
unfilled (filled = false) or undefined bits. Instead users now have to additionally addfilled = falseif they
explicitly want this behaviour. - Renamed the generated
as_bytesmethod for#[bitfield]structs tointo_bytes. It now takesselfinstead of&self
and returns the byte array by value instead of reference. This change was necessary for working properly with the new
#[repr(uN)]feature. - Fixed a bug with
#[bitfield(specifier = true)]bitfields that were not aligned to have a power-of-two bytes.
- (Thanks @jam1garner): The
-
0.9.026 Oct 2020Release notes
Open source →0.9.0 (2020-10-26)
- Add
#[bitfield(specifier = bool)]parameter with which it now is possible to have bitfield structs automatically also
implement themodular_bitfield::Specifiertrait which makes it possible to have bitfields as fields of bitfields. - No longer generates an
unsafe fn from_bytes_unchecked. Now generates a safefn from_bytesthat is basically identical.
The difference is that we no longer consider bitfields containing invalid bit patterns as invalid since generated getters
will protect their access anyways. - Update crate documentation and README.
- Add
-
0.8.025 Oct 2020Release notes
Open source →Release Notes: 0.8.0 (2020-10-25)
- The
#[derive(BitfieldSpecifier)]now allows an amount of variants that is not a power of two via
the new attribute#[bits = N]whereNis the bit width of the deriving enum. (Thanks @lkolbly) - Add
Specifierimplementations foru8,u16,u32,u64andu128. - The
#[bitfield]macro now additionally generates getters for expected failures just as it already
does for the various setters. For a fieldathe new fail-safe getter is calleda_or_errand returns
aResult. - Silence repetitive
dead_codewarnings originating from generated#[bitfield]getters and setters. - Improve error span information in a few use cases.
- Cleaned up backend code for
modular_bitfieldcrate and its generated code.
- The
-
0.7.018 Oct 2020Release notes
Open source →Release Notes: 0.7.0 (2020-10-18)
- Tons of macro generated code hygiene improvements for both
#[bitfield]and#[derive(BitfieldSpecifier)]. #[bitfield]now produceswith_{}andwith_{}_checkedmethods that takeselfand returnSelf. (Thanks @lkolbly)- This is useful for building up your bitfields without the need of a mutable reference.
#[bitfield]generated getters now are the same identifiers as their fields. (Thanks @Qyriad)- Previously for a field
ait generatedfn get_a(..)but now it generatesfn a(..)instead.
- Previously for a field
#[bitfield]now properly inherits visibility modifiers for all fields onto their generated getters and setters. (Thanks @WorldSEnder)- Remove
TryFromimplementation from#[bitfield]generated structs since it never was really safe.- It didn't check for invalid bit patterns and thus could trigger undefined behaviour.
- The
#[bitfield]generatednewconstructor is now aconst fn. - Rename the
#[bitfield]generatedto_bytestoas_bytes.- Also it now returns a refernce to an array, e.g.
&[u8; N]instead of a slice.
- Also it now returns a refernce to an array, e.g.
- The
#[bitfield]macro now generates anunsafe fn from_bytes_uncheckedthat allows constructing from raw bytes.- This is meant as an
unsafereplacement for the removedTryFromimplementation. - We plan to create safer alternatives in future updates.
- This is meant as an
- Updated all benchmarks to use the
criterioncrate. - Fixed a parsing bug that
enumvariant names sometimes could clash with Rust keywords. (Thanks @Qyriad) - Fixed a bug that caused getters to sometimes read with extra invalid bits. (Thanks @crzysdrs)
- Fixed an issue that was caused by single bit manipulations. (Thanks @crzysdrs)
- Tons of macro generated code hygiene improvements for both
-
0.6.006 Sep 2019Nothing published for this version
-
0.5.025 May 2019Nothing published for this version
-
0.4.024 May 2019Nothing published for this version
-
0.3.023 May 2019Nothing published for this version
-
0.2.023 May 2019Nothing published for this version
-
0.1.022 May 2019Nothing published for this version