Macro rfw_backend::bitarr

macro_rules! bitarr {
    (const $order:ty, $store:ty; $val:expr; $len:expr) => { ... };
    (const $val:expr; $len:expr) => { ... };
    (const $order:ident, Cell<$store:ident>; $($val:expr),* $(,)?) => { ... };
    (const $order:ident, $store:ident; $($val:expr),* $(,)?) => { ... };
    (const $($val:expr),* $(,)?) => { ... };
    ($order:ty, $store:ty; $val:expr; $len:expr) => { ... };
    ($val:expr; $len:expr) => { ... };
    ($order:ident, Cell<$store:ident>; $($val:expr),* $(,)?) => { ... };
    ($order:ident, $store:ident; $($val:expr),* $(,)?) => { ... };
    ($order:path, Cell<$store:ident>; $($val:expr),* $(,)?) => { ... };
    ($order:path, $store:ident; $($val:expr),* $(,)?) => { ... };
    ($($val:expr),* $(,)?) => { ... };
}

Constructs a new BitArray from a bit-pattern description.

This macro takes a superset of the vec! argument syntax: it may be invoked with either a sequence of bit expressions, or a single bit expression and a repetition counter. Additionally, you may provide the names of a BitOrder and a BitStore implementor as the BitArray’s type arguments.

Argument Rules

Bit expressions must be integer literals. Ambiguity restrictions in the macro syntax forbid the use of identifiers to existing variables, even const values. These are converted to bool through the expression $val != 0. Any non-zero enteger becomes true, and 0 becomes false.

You may use any name or path to a BitOrder implementation. However, the identifier tokens Lsb0, Msb0, and LocalBits are matched directly and specialized to have compile-time constructions, whereäs any other name or path will not be known to the macro, and will execute at runtime.

The BitStore argument must be the name of an unsigned integer fundamental, an atomic, or a Cell<> wrapper of that unsigned integer. These are matched by token, not by type, and no other identifier is accepted. Using any other token will cause the macro to fail.

const Production

Prepending the argument list with const (so bitarr!(ARGS…) becomes bitarr!(const ARGS…)) causes the macro to only expand to code that can be used in const contexts. This limits any supplied ordering to be only the tokens Lsb0, Msb0, and LocalBits; no other token is permitted, even if the token resolves to the same ordering implementation.

The macro expands into code that can be used to initialize a const or static binding. This is the only way to construct a BitArray in const contexts, until the const system permits generics and trait methods.

Examples

use bitvec::prelude::*;
use core::cell::Cell;

radium::if_atomic! { if atomic(32) {
  use core::sync::atomic::AtomicU32;
} }

let a: BitArray = bitarr![0, 1, 0, 1, 2];
assert_eq!(a.count_ones(), 3);

let b: BitArray = bitarr![2; 5];
assert!(b.all());
assert!(b.len() >= 5);

let c = bitarr![Lsb0, Cell<u16>; 0, 1, 0, 0, 1];
radium::if_atomic! { if atomic(32) {
  let d = bitarr![Msb0, AtomicU32; 0, 0, 1, 0, 1];
} }

let e: BitArr!(for 20, in LocalBits, u8) = bitarr![LocalBits, u8; 0; 20];