Rework the #[flag_name] feature and re-stabilize as #[bitflags(flag_name)] #487
No reviewers
Labels
No labels
bug
good first issue
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-bitflags/bitflags!487
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/macro-expansion"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #486
In #483, we added macro code to recognize and handle a custom
#[flag_name]attribute for setting the name of a flag. This was being expanded under theexpr_safe!macro, which already recurses on each attribute on the expression. Combining the two pushed largerbitflagsinvocations over the default 128 recursion depth limit.This PR pulls the logic for computing the flag name out of the logic for wrapping expressions, so we recurse to the same depth as before.
While working on this I've also cleaned up the workaround for #320 which has been fixed for a few years now. I've also re-organized our compile-pass tests just for a bit of housekeeping.
Since we have a second chance to look at this feature, I've namespaced the attribute as
#[bitflags(flag_name = "value")]instead of the raw#[flag_name = "value"].The https://github.com/bitflags/bitflags/pull/487/commits/e4ed6354c7f31522a42b84dc2fff97ea7c400282 commit appears to trigger an ICE with Rust 1.69, see https://github.com/nix-rust/nix/pull/2812, https://github.com/rust-lang/rust/issues/110848.