You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
macro pattern ($($arg:expr)*) should be illegal #48220
which is reasonable because it leads to ambiguities (e.g. "a b -c" could be three expressions "a", "b", and "-c", or two, "a" and "b-c"). (If you're curious, the implementation picks the second choice in this case).
but the manual does not allow space as a separator in an expr list
Can you show more precisely what language in the link makes you say this? I don't see anything on limitations of lists.
The argument I find much more compelling is what you mentioned in the user's thread, that the following
macro_rules! foo {
($a:expr $b:expr) => {};
}
is forbidden.
because it leads to ambiguities
I fear much worse; that the way such invocations are parsed may even change as the grammar of expressions is extended. This would seem to defeat the whole purpose of the follow-set rules! (but of course! They've been entirely circumvented...)
In response to ExpHP: It's in the last part of the "Syntactic Requirements" section, copied below.
There are additional rules regarding the next token after a metavariable:
expr and stmt variables may only be followed by one of: => , ;
Clearly allowing ($($arg:expr)*) breaks this rule.
Durka: yes, same problem, thank you for linking this.
Sorry if I am stating the obvious, but there's no good way of allowing space-separated expressions in this context. In addition to the "-" operator, there are function calls (is f (x) one or two expressions?), vectors (a [3]) and I don't know what else (my experience with Rust is about 4 days).
I think calling this "space-separated" is a misnomer, because the same problem occurs without any spaces in the input at all, just depending on how the tokens are combined.
Thanks, agree, "space-separated" is not good. It's more like "without a separator" or more precisely "without a separating token" since whitespace can separate tokens. In any case I don't think there's any confusion here.
Whether or not the book suggests this or not, the syntax is still allowed by rustc. The movement to fix it, or even lint on it for future deprecation (#55373, #56575) seems to have stalled.
Activity
ExpHP commentedon Feb 14, 2018
Can you show more precisely what language in the link makes you say this? I don't see anything on limitations of lists.
The argument I find much more compelling is what you mentioned in the user's thread, that the following
is forbidden.
I fear much worse; that the way such invocations are parsed may even change as the grammar of expressions is extended. This would seem to defeat the whole purpose of the follow-set rules! (but of course! They've been entirely circumvented...)
durka commentedon Feb 14, 2018
I think this may be the same as #44975.
semenzato commentedon Feb 14, 2018
In response to ExpHP: It's in the last part of the "Syntactic Requirements" section, copied below.
Clearly allowing ($($arg:expr)*) breaks this rule.
Durka: yes, same problem, thank you for linking this.
Sorry if I am stating the obvious, but there's no good way of allowing space-separated expressions in this context. In addition to the "-" operator, there are function calls (is f (x) one or two expressions?), vectors (a [3]) and I don't know what else (my experience with Rust is about 4 days).
cuviper commentedon Feb 15, 2018
I think calling this "space-separated" is a misnomer, because the same problem occurs without any spaces in the input at all, just depending on how the tokens are combined.
semenzato commentedon Feb 15, 2018
Thanks, agree, "space-separated" is not good. It's more like "without a separator" or more precisely "without a separating token" since whitespace can separate tokens. In any case I don't think there's any confusion here.
Auto merge of #55373 - estebank:macro-rep, r=<try>
steveklabnik commentedon Apr 1, 2020
Triage: this text is no longer in the book; it seems like a warning was added. I'm gonna call this fixed. Please let me know if this is not the case!
durka commentedon Apr 1, 2020
Whether or not the book suggests this or not, the syntax is still allowed by rustc. The movement to fix it, or even lint on it for future deprecation (#55373, #56575) seems to have stalled.