Skip to content

macro_rules treating ';' as an ident #26444

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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.
# for free to join this conversation on GitHub. Already have an account? # 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