Skip to content
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_rules treating ';' as an ident #26444

Closed
durka opened this issue Jun 19, 2015 · 6 comments · Fixed by #42913
Closed

macro_rules treating ';' as an ident #26444

durka opened this issue Jun 19, 2015 · 6 comments · Fixed by #42913
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) P-low Low priority T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@durka
Copy link
Contributor

durka commented Jun 19, 2015

This playpen contains a macro with two *-repeating arguments, plus a non-repeating argument sandwiched between them. It works fine when the repeating arguments are supplied, but when I try to leave out the first one, rustc claims the syntax is ambiguous. But I can't see why.

@steveklabnik steveklabnik added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label Jun 23, 2015
@jFransham
Copy link
Contributor

I have this problem with = too, in the pattern ( $fname:ident $( $arg:pat )* = ). I get "ambiguous syntax" for the = symbol.

@bluss
Copy link
Member

bluss commented Sep 10, 2015

It's a known limitation of macros, see https://doc.rust-lang.org/book/macros.html#syntactic-requirements.

The macro system does not deal with parse ambiguity at all.

@durka
Copy link
Contributor Author

durka commented Sep 10, 2015

What's strange is that it's perfectly capable of using ; to terminate the repeating ident matcher, because ; clearly isn't an ident. But it won't use that fact to disambiguate the match at the first token.

@durka
Copy link
Contributor Author

durka commented Sep 10, 2015

Also, the example at that point in the book doesn't make any sense. Neither $e:expr nor E can follow $t:ty.

@brson
Copy link
Contributor

brson commented Mar 9, 2017

Current output:



rustc 1.15.1 (021bd294c 2017-02-08)
error: local ambiguity: multiple parsing options: built-in NTs ident ('beginning') or 1 other option.
 --> <anon>:9:25
  |
9 |     println!("{}", foo!(; f ;));
  |                         ^

Compilation failed.

@brson brson added T-lang Relevant to the language team, which will review and decide on the PR/issue. P-low Low priority labels Mar 9, 2017
@nikomatsakis
Copy link
Contributor

The problem is not that ; is considered as an identifier (see e.g. https://is.gd/lJjUHz), but rather that once we start parsing a "fragment" (like $x:tt), parsing must succeed or macro parsing aborts. Fixing this turned out to be quite complex, and I expect we'll only address it in macros 2.0. Closing.

kennytm added a commit to kennytm/rust that referenced this issue Jul 7, 2017
bors added a commit that referenced this issue Jul 11, 2017
…seyfried

Only match a fragment specifier the if it starts with certain tokens.

When trying to match a fragment specifier, we first predict whether the current token can be matched at all. If it cannot be matched, don't bother to push the Earley item to `bb_eis`. This can fix a lot of issues which otherwise requires full backtracking (#42838).

In this PR the prediction treatment is not done for `:item`, `:stmt` and `:tt`, but it could be expanded in the future.

Fixes #24189.
Fixes #26444.
Fixes #27832.
Fixes #34030.
Fixes #35650.
Fixes #39964.
Fixes the 4th comment in #40569.
Fixes the issue blocking #40984.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) P-low Low priority T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants