Thanks for the PR @flier!

It looks like we'll have to bump our minimum supported Rust version to 1.28.0 to support the representation. That release is about 12 months old now so I think this is a reasonable change.

I think this is a reasonable change and it would help me avoid boilerplate w/ FFI stuff.

I don't think an MSRV bump is needed, we can just check the version in the build.rs like we do for const fn stuff.

@KodrAus does that sound reasonable? @flier I'm happy to take this over if you don't have time.

Hi @josephlr

I have added a bitflags_repr_transparent feature gate for the #[repr(transparent)] attribute, could you help me to review the changes?
Thanks

Hi @flier, can you update the MR? thanks

Thanks for your patience on this one @flier. Wow I really let this sit for a long time! 1.28.0 is now really quite old so I think we should be comfortable just bumping to it if we haven't already and avoid needing to add feature gates.

I was wondering whether #[repr(transparent)] came with a bit pattern guarantee (in bitflags we currently enforce that all set bits correspond to valid flags, so not all bit patterns of the underlying integer are necessarily valid bitflags), but since non-zero types like NonZeroUsize are also #[repr(transparent)] I think we're safe here.

If you'd like to update this PR to just unconditionally add the #[repr(transparent)] attribute or if somebody else would like to add that we can merge this in.

In #240 we bumped all the way up to 1.45.0, so can definitely unconditionally add the #[repr(transparent)] flag now 🙂

thanks! release time? :)

This breaks at least the crates nix and rusqlite, because they both use #[repr(C)] on "enum structs"

also wgpu-types and naga, which already added #[repr(transparent)]

error[E0692]: transparent struct cannot have other repr hints
    --> /.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-types-0.7.0/src/lib.rs:2791:12
     |
2779 | / bitflags::bitflags! {
2780 | |     /// Flags for which pipeline data should be recorded.
2781 | |     ///
2782 | |     /// The amount of values written when resolved depends
...    |
2791 | |     #[repr(transparent)]
     | |            ^^^^^^^^^^^
...    |
2812 | |     }
2813 | | }
     | |_^
     |
     = note: this error originates in the macro `bitflags::bitflags` (in Nightly builds, run with -Z macro-backtrace for more info)

Thanks for the reports everyone 👍 I've gone ahead and yanked 1.3.0 so we can fix this up. I really wish we had something like crater we could use to test things like this. But in the meantime I'll add some compilation tests that include other reprs