gh-bitflags/bitflags
Watch
1
0
Fork
You've already forked bitflags
 0
Code Issues 10 Pull requests Releases 53 Activity

Add allowable warnings for multiple flags with equal values #490

New issue
Open
opened 2026-06-16 16:02:30 -05:00 by inner-daemons · 0 comments
inner-daemons commented 2026-06-16 16:02:30 -05:00 (Migrated from github.com)

I'm not sure if it would fit the project, but it would be useful to give a warning when two flags have exactly the same bits.

In wgpu we use bitflags for features and capabilities, and these are constantly being added in multiple open pull requests. We go through the bits in order, so each of these open pull requests usually tries to use the same next bit. Then when one of them gets merged everybody else has to figure out why their feature subtly stopped working, which can be confusing.

I propose some new compile-time warning for when multiple flags have the exact same value. Of course this could be disabled for certain values with an attribute like #[allow_duplicate], or globally on the whole bitflag type. Perhaps it is even opt in to the bitflag type, with an attribute like #[disallow_duplicate].

I might be willing to work on this myself if it is blessed by the maintainers.

Not sure exactly how this would fit into semver or if thats out of scope for the project. Just a random idea I had.

I'm not sure if it would fit the project, but it would be useful to give a warning when two flags have exactly the same bits. In wgpu we use bitflags for features and capabilities, and these are constantly being added in multiple open pull requests. We go through the bits in order, so each of these open pull requests usually tries to use the same next bit. Then when one of them gets merged everybody else has to figure out why their feature subtly stopped working, which can be confusing. I propose some new compile-time warning for when multiple flags have the exact same value. Of course this could be disabled for certain values with an attribute like `#[allow_duplicate]`, or globally on the whole bitflag type. Perhaps it is even opt in to the bitflag type, with an attribute like `#[disallow_duplicate]`. I might be willing to work on this myself if it is blessed by the maintainers. Not sure exactly how this would fit into semver or if thats out of scope for the project. Just a random idea I had.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
release/1.x
2.13.2
2.13.1
2.13.0
2.12.1
2.12.0
2.11.1
2.11.0
2.10.0
2.9.4
2.9.3
2.9.2
2.9.1
2.9.0
2.8.0
2.7.0
2.6.0
2.5.0
2.4.2
2.4.1
2.4.0
2.3.3
2.3.2
2.3.1
2.3.0
2.2.1
2.2.0
2.1.0
2.0.2
2.0.1
2.0.0
2.0.0-rc.3
2.0.0-rc.2
2.0.0-rc.1
1.3.2
1.3.1
1.3.0
1.2.1
1.2.0
1.1.0
1.0.5
1.0.4
1.0.3
1.0.2
1.0.1
1.0.0
0.9.1
0.9.0
0.8.2
0.8.1
0.8.0
0.7.1
0.7.0
0.6.0
Labels
Clear labels   
bug

   
good first issue
No labels
bug
good first issue
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-bitflags/bitflags#490
No description provided.