-
Notifications
You must be signed in to change notification settings - Fork 664
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
Open
svix-jplatte
wants to merge
1
commit into
tokio-rs:master
Choose a base branch
from
svix-jplatte:keyword-ident-fields
base: master
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
svix-jplatte
requested review from
yaahc,
carllerche and
davidbarsky
as code owners
April 22, 2024 17:32
svix-jplatte
force-pushed
the
keyword-ident-fields
branch
2 times, most recently
from
April 23, 2024 12:49
bb89679
to
f87f41f
Compare
hds
requested changes
Apr 23, 2024
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.
svix-jplatte
force-pushed
the
keyword-ident-fields
branch
from
April 23, 2024 13:25
f87f41f
to
917065a
Compare
svix-jplatte
force-pushed
the
keyword-ident-fields
branch
from
May 2, 2024 11:26
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.
svix-jplatte
force-pushed
the
keyword-ident-fields
branch
from
May 21, 2024 15:03
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.
svix-jplatte
force-pushed
the
keyword-ident-fields
branch
from
June 4, 2024 09:37
8f6bb60
to
6a2c043
Compare
And after another rebase, we have an ICE! Fix seems to be rust-lang/rust#125493. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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