lymia / enumset Goto Github PK

Would be nice for union-ing an iterator of EnumSets. :)

Could also implement std::iter::Product for intersections. Thoughts?

Hi, updating my depedencies, I just find out that semver seems to be broke between 0.3.12 and 0.3.13.

My set look like:

enum_set_type!{
  pub enum Direction
  {
    #[derive(Debug, Clone, Component, Eq, PartialEq)]
    N, NE, SE, S, SW, NW, UP, DN
  }
}

and are matched like

pub fn ao(e: EnumSet<Direction>) -> &'static str {
const E0:		  EnumSet<Direction> = enum_set!(DN | UP | N | NE | SE | S | SW | NW);
match e {
E0 => "/nano-data/textures/ao_cul/ao_DN-UP-N-NE-SE-S-SW-NW.png",
EnumSet{ .. } =>  {
 println!("cannot find {:?}", e ); 
 unreachable!()
}
}
}

It used to work fine, now I get a :

error: to use a constant of type enumset::EnumSet in a pattern, enumset::EnumSet must be annotated with #[derive(PartialEq, Eq)]

I would love to have some methods like intersection, union etc. const. Would help me avoid using lazy_static! or once_cell::Lazy at a bunch places in my code. This will probably require upping the MSRV. If you are open to this, I can send in a pull request.

I have two data structures indexed by T: EnumSetType.

/// A bitset similar to [`BitMatrix`][super::BitMatrix],
/// but with a fixed column and row count, one row per `T` variant.
pub struct EnumBitMatrix<T: EnumSetType>(Box<[u32]>, PhantomData<T>);

/// A MultiMap stored in a [`JaggedArray`].
///
/// The key set need to be bound and exhaustively known at compile time,
/// ie: it must be an enum derived with `#[derive(EnumSetType)]`.
///
/// Use it as follow:
/// `EnumMultiMap<MyEnumSet, String, { (MyEnumSet::BIT_WIDTH - 1) as usize }>`
pub struct EnumMultiMap<K: EnumSetType, V, const CLM: usize>

I use the bit position of T as index in my collection. I also use BIT_WIDTH to size the arrays used in those data structures. It's very pleasant.

However, there is no way to get a bit position outside of EnumSeTypePrivate::enum_into_u32, and no const way of getting the bit width outside of EnumSeTypePrivate::BIT_WIDTH. I don't want to rely on private/unstable API, so I'm opening an issue to request a "stable" way of getting those.

An explicit representation doesn't solve this. The BIT_WIDTH and enum_into_u32 is independent from the representation of T, Ideally I can have as many variants as I want.

I imagine the "bit position" is problematic for enums defined with explicit variant values, so I guess this needs to be part of a new trait only valid for enums without explicit variant values. For example, EnumBitSetType.

What do you think of this? Would you be open to a PR for such a new trait?

I made a struct along the lines of:

#[derive(EnumSetType, Serialize, Deserialize, Debug)]
enum ItemType { A, B, C }

#[derive(Serialize, Deserialize, Debug)]
struct Item {
  name: String,
  types: EnumSet<ItemType>
}

I get an error like this:

error[E0277]: the trait bound `enumset::EnumSet<ItemType>: _IMPL_DESERIALIZE_FOR_ItemType::_serde::Serialize` is not satisfied
   --> src\main.rs:250:5
    |
250 |     types: EnumSet<ItemType>,
    |     ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `_IMPL_DESERIALIZE_FOR_ItemType::_serde::Serialize` is not implemented for `enumset::EnumSet<ItemType>`

I am fairly new to Rust but should this work? I installed cargo-tree and there seems to be no version conflicts. Here is what my toml deps looks like:

[dependencies]
sxd-document = "0.3.2"
sxd-xpath = "0.4.2"
enumset = "1.0.0"
serde = { version = "1.0", features = ["derive"] }

The clippy::expl_impl_clone_on_copy lint checks for explicit implementations of Clone on types that implement Copy, which can be a problem. It's not here, but clippy isn't smart enough to recognize that.

It would be useful to have git tags for the releases made to crates.io.

$ cargo build

Compiling enumset_derive v0.5.0 (/home/mrlogick/enumset/enumset_derive)
error[E0432]: unresolved import `syn::export`
  --> enumset_derive/src/lib.rs:10:10
   |
10 | use syn::export::Span;
   |          ^^^^^^ could not find `export` in `syn`

error: aborting due to previous error

Please add an example of how to create an empty enumset. It may seem obvious to you, but it isn't. This is partly macro magic, and Google isn't much help either. For those that need a reminder:

#[derive(EnumSetType, Debug)]
enum Permissions {
    Read,
    Edit,
}
let permissions = EnumSet::<Permissions>::new();

The empty set is actually the most common initialization pattern.

This is one of those Rust things: if you don't already know, you'll likely not find out.

Besides, this is horrible syntax. Why not add some alternative #[derive()] which enables:

let new_set = Permissions::None;

Fedora packager here; I'm packaging crates enumset and enumset_derive as Fedora packages.

Would you mind adding README and LICENSE files in the crates?

Starting with enumset 1.0.1, deriving EnumSetType now requires importing EnumSet, while it was not required in 1.0.

As a result, this breaks compilation for any library only importing EnumSetType to derive it. Since 1.0.1 (and later) are semver-compatible with 1.0, unless a library explicitly forbids it, cargo will default to fetching the latest version of enumset (right now 1.0.3), exposing the issue.

Hi, the CI badge link in the README is a broken link to travis-ci.

I ran into a situation where I needed to find the greatest item in an EnumSet. Although this can be done straightforwardly with Iterator::last, it would be more efficient to use DoubleEndedIterator::next_back…if EnumSetIter implemented DoubleEndedIterator, which it currently doesn't.

The clippy unused_unit lint is triggered in rust 1.69.0 and later builds.

#[deny(clippy::unused_unit)]
#[derive(enumset::EnumSetType)]
enum Example {
  One,
  Two,
}

The compiler output, even with -Z macro-backtrace isn't particularly helpful here, so I can't help identify the cause (the quoted line seems fine).

874 | pub fn derive_enum_set_type(input: TokenStream) -> TokenStream {
    | -------------------------------------------------------------- in this expansion of `#[derive(EnumSetType)]`

I expected this to work. Am I doing something wrong?

#[derive(EnumSetType)]                                              
pub struct MyAwesomeEnum(foo::my_enum);      

Hi, enumset is depended upon by the stm32f3xx-hal crate v0.9.0 under the enumset feature flag, which is enabled by default. However, the recent 1.0.9 of enumset release broke my builds with the following error:

error[E0463]: can't find crate for `std`
  |
  = note: the `thumbv7em-none-eabihf` target may not support the standard library
  = note: `std` is required by `serde` because it does not declare `#![no_std]`

For more information about this error, try `rustc --explain E0463`.
error: could not compile `serde` due to previous error

Caused by:
  process didn't exit successfully: `rustc --crate-name serde C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\serde-1.0.136\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=s -C linker-plugin-lto -C debuginfo=2 --cfg "feature=\"default\"" --cfg "feature=\"std\"" -C metadata=4f4c1def9fa00289 -C extra-filename=-4f4c1def9fa00289 --out-dir C:\Users\drand\Documents\src\rust-cam\camtrig-firmware\target\thumbv7em-none-eabihf\release\deps --target thumbv7em-none-eabihf -L dependency=C:\Users\drand\Documents\src\rust-cam\camtrig-firmware\target\thumbv7em-none-eabihf\release\deps -L dependency=C:\Users\drand\Documents\src\rust-cam\camtrig-firmware\target\release\deps --cap-lints allow -C link-arg=-Tlink.x -C link-arg=-Tdefmt.x --cfg no_std_atomic64 --cfg no_std_atomic` (exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: build failed

Indeed stm32f3xx-hal targets thumbv7em-none-eabihf for which std is not available. It looks like the new proc-macro-crate dependency introduced in 6cd9f94 somehow causes this regression. I have not dug further.

Forcing the build to use b318bf1 with the following in my Cargo.toml worksaround the error:

[patch.crates-io]
enumset = { git="https://github.com/Lymia/enumset", rev="b318bf1aaa69c863c7ec26475782cf4f69e0468b" }

If I update to 6cd9f94, however, I get the error again.

#[macro_use]
extern crate enumset;
use enumset::EnumSet;

enum_set_type! {
pub enum Flag {
A, B, C, D, E, F, G, H, I,
}
}

fn main() {
let set = EnumSet::::empty();
println!("{}", set.contains(Flag::I)); // panic! in <enumset::EnumSet>::mask
}

EnumSetIter derives an implementation of Ord, which makes it annoying to use Iterator::max due to the conflicting name with Ord::max. This can be worked around with iter.map(|v| v).max(), or by manually disambiguating the call with Iterator::max(iter), but both solutions feel a bit hacky.

I cloned and tested a fix for this by removing the Ord implementation, and the tests still compile and pass - I'm not sure why PartialOrd/Ord are implemented on an iterator in the first place. Unfortunately, removing the Ord implementation would be a breaking change according to semantic versioning.

As explained in the issue title, EnumSetType generates a "use of irregular braces" warning that shows itself when a crate user adds a #[derive(EnumSetType) attribute to an enum.

This can be worked around by allowing the warning, but that's not so elegant.

Clippy warning

rustc version

rustc 1.55.0-nightly (b3d11f95c 2021-07-04)

clippy version

clippy 0.1.55 (b3d11f9 2021-07-04)

#[derive(EnumSetType, Serialize, Deserialize)]
#[enumset(serialize_as_list)]
#[serde(remote = "UnitType")]
pub enum UnitTypeDSL {
    Explorer,
    Town,
    City,
    Dahan,
}

This code doesn't compile, complaining that Serialize is not implemented.