Simplify macros for target-modifier and mitigation flags#155389
Simplify macros for target-modifier and mitigation flags#155389Zalathar wants to merge 1 commit intorust-lang:mainfrom
Conversation
rustbot
added
S-waiting-on-review
|
r? @mati865 rustbot has assigned @mati865. Use Why was this reviewer chosen?The reviewer was selected based on:
|
| box_noalias: bool = (true, parse_bool, [TRACKED], | ||
| "emit noalias metadata for box (default: yes)"), | ||
| branch_protection: Option<BranchProtection> = (None, parse_branch_protection, [TRACKED TARGET_MODIFIER], | ||
| branch_protection: Option<BranchProtection> = (None, parse_branch_protection, [TRACKED] { TARGET_MODIFIER: BranchProtection }, |
There was a problem hiding this comment.
A limitation of the ${ignore(..)} approach is that we can't just accept a bare TARGET_MODIFIER; we have to accept some kind of variable as well (in this case an identifier).
Because of that, I took the opportunity to give the enum variants camel-case names instead of recycling the struct-field names.
| $( { TARGET_MODIFIER: $tmod_variant:ident } )? | ||
| $( { MITIGATION: $mitigation_variant:ident } )? |
There was a problem hiding this comment.
I tried a lot of different syntaxes here, and { FOO: Bar } is what I eventually settled on.
Many of the alternatives I tried ran into parse ambiguity problems.
At one point I was accepting $tmod:vis TARGET_MODIFIER to allow an empty visibility, but that ended up not working when I had to support MITIGATION at the same time.
3 participants
The macros used for handling command-line flags that are “target modifiers” or “mitigations” are quite complicated, and can be significantly simplified by tweaking their syntax and by making use of
${ignore(..)}metavars.It's possible that more code could be moved out of macros (e.g. declaring some of the enums by hand), but that can be investigated in a potential follow-up.
There should be no change to compiler behaviour.