Release 0.7.10

• Fix a case where the #[bitflags] macro would access the crate through enumflags2::... instead of ::enumflags2::.... This makes the generated code more robust and avoids triggering the unused_qualifications lint. (#58)
• Rework the proc-macro to use syn with the derive feature (as opposed to full). This reduces the cargo build time for enumflags2 by about 20%.

Release 0.7.9

• The BitFlag trait now includes convenience re-exports for the constructors of BitFlags. This lets you do MyFlag::from_bits instead BitFlags::<MyFlag>::from_bits where the type of the flag cannot be inferred from context (thanks @ronnodas).
• The documentation now calls out the fact that the implementation of PartialOrd may not be what you expect (reported by @ronnodas).

Release 0.7.8

• New API: BitFlags::set. Sets the value of a specific flag to that of the bool passed as argument. (thanks, @m4dh0rs3)
• BitFlags now implements PartialOrd and Ord, to make it possible to use it as a key in a BTreeMap.
• The bounds on the implementation of Hash got improved, so that it is possible to use it in code generic over T: BitFlag.

Release 0.7.7

This release fixes a soundness issue in the make_bitflags! macro. Previously, code like this was accepted:

#[bitflags]
#[repr(u8)]
#[derive(Copy, Clone, Debug)]
enum Test {
    A = 1,
    B = 2,
}

impl Test {
    const C: u8 = 69;
}

fn main() {
    let x = make_bitflags!(Test::{C});
}

Iterating over x would then create values of Test with bit patterns that don't correspond to any of the variants, which is undefined behavior.

This bug has been introduced in 0.7.0, together with the make_bitflags! macro itself.

I don't think it is likely that this was actually present in anyone's code, but in an abundance of caution, I have yanked all affected versions.

This issue has been assigned RUSTSEC-2023-0035.

Release 0.7.6

• Update to syn 2.0 (thanks to @mwkmwkmwk)
• Bump MSRV to 1.56.0 to support the above
• Update crate metadata to compensate for gender drift :3

Release 0.7.5

BitFlags now implements Display, which only shows the flag list (without the binary representation).

Release 0.7.4

• Added BitFlags::len, which returns the number of flags set.
• Added BitFlags::exactly_one, which converts a singleton flag set to the flag. Returns Option::None if the input is not a singleton.
• The iterator returned by BitFlags::iter now implements ExactSizeIterator and FusedIterator.
• BitFlags now implements IntoIterator.

Release 0.7.3

• The code generated by the macro no longer triggers Clippy's use_self lint. To prevent further issues of this kind, Clippy now runs on the test suite in CI, with the pedantic and nursery lints enabled too.
• Some more functions are marked #[inline] now. This will probably improve downstream performance in non-LTO builds.
• Some more functions are marked #[must_use] now, at the suggestion of Clippy. If this triggers, your code was probably weird and/or broken, but it's not really a mistake I'd expect anyone to make.
• Minor documentation improvements.

Release 0.7.2

The iterator returned by BitFlags::iter now implements Clone.

Release 0.7.0

Release 0.7.0

• Breaking change: instead of #[derive(BitFlags)], the macro is now #[bitflags]
  • This allows a long-awaited feature: when a discriminant isn't provided, the macro will choose an unused bit for you.
• You can now create instances of BitFlags without repeating the name: make_bitflags!(MyFlags::{Foo, Bar}) instead of MyFlags::Foo | MyFlags::Bar. Works in a const fn, too!
• Many new APIs that allow working with BitFlags in a const fn despite rustc limitations
• Many improved error messages
• Implementation details do not show up in user documentation anymore
• Breaking change: rename the RawBitFlags trait to BitFlag - there's nothing raw about it
• Breaking change: the not_literal feature doesn't exist, the relevant functionality is now enabled by default - there is no concern about confusing error messages anymore
• Breaking change: the #[repr(u??)] attribute is now required - previously, Rust's default of usize was used, which is a terrible idea for the size of a bitfield
• Breaking change: BitFlags::new is now called from_bits_unchecked - new suggests that this is the main, preferred way of creating BitFlags. This is not the case.
• the value returned by Default::default can now be customized with #[bitflags(default = Foo | Bar)]