-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Macro future proofing #550
Conversation
# Unresolved questions | ||
|
||
1. What should the FOLLOW sets for `item`, `path`, and `meta` be? | ||
2. Should the `FOLLOW` set for `ty` be extended? In practice, `RArrow`, |
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.
Forgot one, of course: =
Oh, and a massive +1 to the overall idea here. |
+1, I'm convinced this is necessary. Detailed futures of some NTs are a bit unclear, though. |
@cmr are there any changes you'd like to make to this RFC before we merge it? |
@nick29581 maybe. The algorithm here no longer reflects the implementation, and the follow sets are subtly incorrect. |
@cmr Ok, ping me when you are happy and I'll merge it |
@nick29581 this is ready. |
|
||
- `FOLLOW(pat)` = `{FatArrow, Comma, Eq}` | ||
- `FOLLOW(expr)` = `{FatArrow, Comma, Semicolon}` | ||
- `FOLLOW(ty)` = `{Comma, FatArrow, Colon, Eq, Gt, Ident(as)}` |
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.
@cmr, was there a reason for not including Semicolon on this list as well?
It's handy when defining matchers like $( fn $n:ident( $(p:ident : $t:ty),* ) -> $r:ty ; )*
(note the trailing 'ty')
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.
No, that was indeed an oversight
sent from my phone
On Jan 23, 2015 12:24 AM, "Vadim Chugunov" notifications@github.com wrote:
In text/0000-macro-future-proofing.md
#550 (comment):
continue, else, reject.
- If
T
has the form$(...)U+
or$(...)U*
for some tokenU
, runthe algorithm on the contents with `F` set to `U`. If it accepts,
check that the last token in the sequence can be followed by `F`. If
so, accept. Otherwise, reject.
+This algorithm should be run on every matcher in every
macro_rules
+invocation, withF
asEOF
. If it rejects a matcher, an error should be
+emitted and compilation should not complete.
+
+The current legal fragment specifiers are:item
,block
,stmt
,pat
,
+expr
,ty
,ident
,path
,meta
, andtt
.
+
+-FOLLOW(pat)
={FatArrow, Comma, Eq}
+-FOLLOW(expr)
={FatArrow, Comma, Semicolon}
+-FOLLOW(ty)
={Comma, FatArrow, Colon, Eq, Gt, Ident(as)}
@cmr https://github.com/cmr, was there a reason for not including
Semicolon on this list as well?
It's handy when defining matchers like $( fn$n:ident( $ (p:ident :
$t:ty),* ) -> $r:ty ; )* (note the trailing 'ty')—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rfcs/pull/550/files#r23432570.
(RFC was accepted and has been heavily amended since; current text is: https://github.com/rust-lang/rfcs/blob/master/text/0550-macro-future-proofing.md )
Rendered
Implementation: https://github.com/cmr/rust/tree/macro-input-future-proofing