Add ability to rename flags. #470

New issue

Closed

opened 2025-11-18 10:29:29 -06:00 by WesleyAC · 1 comment

WesleyAC commented 2025-11-18 10:29:29 -06:00 (Migrated from github.com)

• Copy link
• Copy Markdown

Various functions allow interacting with the names of flags as strings (Flag::name, parser, etc). However, these currently must work with the SCREAMING_SNAKE_CASE name of the flag as it appears in the source code, which is not always desirable.

In Arti, we use bitflags for our router status flags, which have specific names assigned to them that do not match the Rust identifiers. It would be convenient to have a way of renaming flags with a attribute macro — here's where this usecase came up.

Various functions allow interacting with the names of flags as strings ([`Flag::name`](https://docs.rs/bitflags/latest/bitflags/struct.Flag.html#method.name), [`parser`](https://docs.rs/bitflags/latest/bitflags/parser/index.html), etc). However, these currently must work with the `SCREAMING_SNAKE_CASE` name of the flag as it appears in the source code, which is not always desirable. In [Arti](https://arti.torproject.org), we use bitflags for our [router status flags](https://spec.torproject.org/dir-spec/consensus-formats.html#item:s), which have specific names assigned to them that do not match the Rust identifiers. It would be convenient to have a way of renaming flags with a attribute macro — [here's where this usecase came up](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3454/diffs#diff-content-4c8b4a5b821efe6b52d4f98dfd87303c58db3166).

KodrAus commented 2025-11-22 16:22:13 -06:00 (Migrated from github.com)

• Copy link
• Copy Markdown

Thanks for the suggestion @WesleyAC 👍 I'm generally against adding custom attributes to the bitflags macros because the macro_rules macros are already mostly busting at the seams.

In this case though, I think it would be reasonable to support through an attribute since there's no other way around the issue. We would basically need to find any places we call stringify! and replace them with another macro call that also accepted the attributes on the flag and figured out what its actual name should be.

Thanks for the suggestion @WesleyAC :+1: I'm generally against adding custom attributes to the `bitflags` macros because the `macro_rules` macros are already mostly busting at the seams. In this case though, I think it would be reasonable to support through an attribute since there's no other way around the issue. We would basically need to find any places we call `stringify!` and replace them with another macro call that also accepted the attributes on the flag and figured out what its actual name should be.

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

Subscribe

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#470

No description provided.