macro_rules!-based bits! macro
#34
Conversation
Codecov Report
@@ Coverage Diff @@
## master #34 +/- ##
=========================================
+ Coverage 58.42% 59.52% +1.1%
=========================================
Files 32 34 +2
Lines 3699 3770 +71
=========================================
+ Hits 2161 2244 +83
+ Misses 1538 1526 -12
Continue to review full report at Codecov.
|
src/macros.rs
Outdated
| (Local, $bits:path, $len:expr, $slice:expr) => { | ||
| &$crate::slice::BitSlice::< | ||
| $crate::order::Local, | ||
| $bits, | ||
| >::from_slice($slice)[.. $len] | ||
| }; |
There was a problem hiding this comment.
This variant can be removed, and all variants can be changed to take bits as a :path
There was a problem hiding this comment.
I think this whole macro can be removed, since it's no longer delegating to any other macros and just always calling the from_slice function…
There was a problem hiding this comment.
The reason it exists is to ensure that the correct prefix is added to Local, Lsb0, and Msb0 orderings.
Without it it would be possible to write Lsb0, but have a different order with that name currently in scope, and the macro would do the wrong thing (as it would assume we wanted the internal Lsb0 ordering, but would build a BitSlice with the wrong type parameter).
src/macros.rs
Outdated
| // bitvec![ endian , type ; 0 , 1 , … ] | ||
| ( $order:path , $bits:ty ; $( $val:expr ),* ) => { | ||
| bitvec![ __bv_impl__ $order , $bits ; $( $val ),* ] | ||
| ($order:ident, $bits:ident; $($val:expr),* $(,)?) => { |
There was a problem hiding this comment.
This should probably have cases for Local, like bits! does.
Alternatively, all of the bitvec![1, 2, 3] variants could call bits! under the hood, as they don't need a dynamic length (which is the only thing bits! doesn't support).
There was a problem hiding this comment.
Yeah, once I think bits! is stabilized enough I want bitvec! to forward to it and just run Self::from_bitslice on the output. Reduces argparse code and forces me to ensure that the library implementation is actually good.
src/macros.rs
Outdated
| // Ensure literal `Msb0`, `Lsb0`, and `Local` always map to our internal | ||
| // definitions of the type, as we've been structurally matching them. | ||
| (Lsb0, $bits:ident, $slice:expr) => { | ||
| $crate::vec::BitVec::< | ||
| $crate::order::Lsb0, | ||
| $bits, | ||
| >::from_slice(&$slice[..]) | ||
| }; | ||
| (Msb0, $bits:ident, $slice:expr) => { | ||
| $crate::vec::BitVec::< | ||
| $crate::order::Msb0, | ||
| $bits, | ||
| >::from_slice(&$slice[..]) | ||
| }; | ||
| (Local, $bits:ident, $slice:expr) => { | ||
| $crate::vec::BitVec::< | ||
| $crate::order::Local, | ||
| $bits, | ||
| >::from_slice(&$slice[..]) | ||
| }; |
There was a problem hiding this comment.
It'd also be fine to make bits take a Path here. We only need it to be an ident for the interface, because only Local, u8, u16, u32, and u64 are supported.
The `__bits_from_slice!` macro ensures that the literal tokens used to accelerate known orderings are correctly mapped to `bitvec` types, and not to any other names that may be in the caller's scope. Because the fundamental types' `from_*e_bytes` constructors are not `const fn`, their presence in literal token sequences did not permit the compiler to elevate the literal to the `'static` lifetime. This meant that using `bits!` to return a `&BitSlice` reference over the arrays generated by the macro failed, as the array literals went out of scope after the `&BitSlice` constructor call exited rather than being hoisted for the duration of the reference's existence. In order to circumvent this, the `from_*e_bytes` constructors are explicitly written out as `const fn` items, and a new helper macro is written in order to dispatch token chunks to the correct constructor. This enables the `bits!` macros to create `static DATA` bindings for the constructed array literals, and thus make the macro return `&'static BitSlice`. In the future, the syntax may be extended to permit mutable buffers.
|
Alright, I'm happy with this. I'm going to pull it into trunk, and call any further tinkering I want to do "maintenance" or "refinement". Thanks so much for making the macro; I never would've thought of how to go about doing that work, and doing it in |
|
I'm rebasing all of recent trunk, including this branch, atop a hotfix commit (to bump the |
This adds a new
macro_rules!based parser for parsingbits!.Marking as WIP, as some things are still slightly broken or unsupported.