-
Notifications
You must be signed in to change notification settings - Fork 683
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
macros: Allow field path segments to be keywords #2925
Conversation
bb89679
to
f87f41f
Compare
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 the tests! Could we please move them into the tracing
crate, since that's where the macros that they're testing are defined.
f87f41f
to
917065a
Compare
917065a
to
3eb7a9a
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
8999a41
to
8f6bb60
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
8f6bb60
to
6a2c043
Compare
This comment was marked as resolved.
This comment was marked as resolved.
6a2c043
to
df0f108
Compare
Finally the stream of unrelated CI failures has ended! 😅 |
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.
Looks good. Thank you!
Motivation
Currently, a keyword like
type
fails compilation as (a path segment of) a field name, for no clear reason. Trying to user#type
instead leads to ther#
being part of the field name, which is unhelpful¹.Solution
Don't require the field path to match a
macro_rules!
expr
, use repeatedtt
instead. I can't tell why this was ever required: The internal stringify macro was introduced in 55091c9#diff-315c02cd05738da173861537577d159833f70f79cfda8cd7cf1a0d7a28ace31b with anexpr
matcher without any explanation, and no tests are failing from making it match upstream'sstringify!
input format.Special thanks to whoever implemented the unstable
macro-backtrace
feature in rustc, otherwise this would have been nigh impossible to track down!¹ this can likely be fixed too by some sort of "unraw" macro that turns
r#foo
intofoo
, but that's a separate change not made in this PR