-
-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support bitflags #528
Support bitflags #528
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have done a first pass on this PR and will continue tomorrow (probably) but I have commented on things that looked a bit odd to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for implementing this! I gave this a second pass and it looks good to me. Left some inline comment about the code. I'd block landing this on adding documentation (API + book); feel free to send this PR to bors when docs are in place.
Feel free to ping me if you'd like some more review on future changes.
macros/src/bitflags.rs
Outdated
} | ||
} | ||
|
||
#[allow(dead_code)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you move the parsing implementation into its own module and e.g. have Input
/ Flag
expose public accessors for the parts that codegen needs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved it to a submodule, but kept it in the same file
match self.table.bitflags.get(&key) { | ||
Some(flags) => { | ||
// FIXME flag print order does not match definition order | ||
// (does some part of the toolchain alphabetically sort them?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
interesting observation: perhaps the linker sorts the symbols alphabetically within a section? maybe we could prefix the symbols (00_$first
, 01_$second
, etc.) so that even after sorting alphabetically they stay in the declaration order? that doesn't have to be addressed in this PR but we should create an issue for this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still looks good to me
bors r+ |
Build succeeded: |
570: Support referring to `Self` in bitflags constants r=Urhengulas a=jonas-schievink The initial bitflags support in #528 had a restriction where referring to the `Self` type in a `bitflags` constant would result in a compile error. Turns out that's entirely unnecessary and I wasn't quite awake when I wrote that code. A minor modification of the generated code avoids this somewhat annoying restriction. Instead of copying the expression verbatim, we can just refer to the associated constant created by the `bitflags` crate, and extract the raw bits. Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Closes #307
TODO:
#[cfg]
on bitflags consts works