Skip to content

macro pattern ($($arg:expr)*) should be illegal #48220

Closed

Description

@semenzato

On rustc 1.21.0 it is legal to write a rule like

($($arg:expr)*) => { println!($($arg),*) }

but the manual does not allow space as a separator in an expr list:

https://doc.rust-lang.org/book/first-edition/macros.html#syntactic-requirements

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).

Activity

  1. ExpHP commented on Feb 14, 2018

    @ExpHP
    Contributor

    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...)

  2. durka commented on Feb 14, 2018

    @durka
    Contributor

    I think this may be the same as #44975.

  3. semenzato commented on Feb 14, 2018

    @semenzato
    Author

    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).

  4. cuviper commented on Feb 15, 2018

    @cuviper
    Member

    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.

  5. semenzato commented on Feb 15, 2018

    @semenzato
    Author

    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.

  6. added
    A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)
    T-langRelevant to the language team
    C-bugCategory: This is a bug.
    on Feb 15, 2018
  7. added a commit that references this issue on Nov 22, 2018
    72bd4c0
  8. steveklabnik commented on Apr 1, 2020

    @steveklabnik
    Contributor

    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!

  9. durka commented on Apr 1, 2020

    @durka
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)C-bugCategory: This is a bug.T-langRelevant to the language team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions