Erroneous expression parsing of macro invocations with paths

[SergioBenitez]

Consider the following rustc internal code which parses an ast::Path and returns an invocation of a macro at that path:

let mut parser = ecx.new_parser_from_tts(args);
let path = parser.parse_path(PathStyle::Mod).expect("path");
MacEager::expr(quote_expr!(ecx, $path!()))

The expected expansion of a procedural macro implemented in this manner is PATH ! ( ). Instead, this expands to PATH erroneously. Said another way, if the code above corresponded to a macro named m, we would expect m!(some_path); to expand to some_path!() when it instead expands to some_path.

Note that if instead an ast::Ident is used in place of the ast::Path above, things work as expected. This corresponds to the code below:

let mut parser = ecx.new_parser_from_tts(args);
let ident = parser.parse_ident().expect("ident");
MacEager::expr(quote_expr!(ecx, $ident!()))

After some investigation, the issue appears to reside in Parser::parse_expr. I've created a repository where the issue can be reproduced: https://github.com/SergioBenitez/path-macro-repro. The repository also includes a work around for the problem (https://github.com/SergioBenitez/path-macro-repro/blob/master/src/lib.rs#L27).

[SergioBenitez]

Likely related to #36662.

[nrc]

Is there any way to observe this without using compiler internals (i.e., macros 1.0 proc macros)?

[SergioBenitez]

@nrc Falling back to a TokenStream, converting that into a String, and parsing as an expression works as expected. Since this is pretty close to what would happen in a proc-macros 2.0 implementation, I would say that it's unlikely this can be seen outside of the compiler internals or proc-macros 1.0.

[Enselic]

Triage: Closing since

• The reproducer repo is gone
• This can't be observed by regular users, only when using compiler internals