Macro patterns are not confused with expressions.

We treat macro calls as expressions (there's appropriate Into impl),
which causes problem if there's expresison and non-expression macro in
the same node (like in the match arm).

We fix this problem by nesting macor patterns into another node (the
same way we nest path into PathExpr or PathPat). Ideally, we probably
should add a similar nesting for macro expressions, but that needs
some careful thinking about macros in blocks: `{ am_i_expression!() }`.
This commit is contained in:
Aleksey Kladov 2020-04-03 15:38:42 +02:00
parent 0e46ed8420
commit da8eb29a2f
7 changed files with 88 additions and 17 deletions

View file

@ -15,16 +15,17 @@ SOURCE_FILE@[0; 33)
LET_STMT@[16; 30)
LET_KW@[16; 19) "let"
WHITESPACE@[19; 20) " "
MACRO_CALL@[20; 25)
PATH@[20; 21)
PATH_SEGMENT@[20; 21)
NAME_REF@[20; 21)
IDENT@[20; 21) "m"
EXCL@[21; 22) "!"
TOKEN_TREE@[22; 25)
L_PAREN@[22; 23) "("
IDENT@[23; 24) "x"
R_PAREN@[24; 25) ")"
MACRO_PAT@[20; 25)
MACRO_CALL@[20; 25)
PATH@[20; 21)
PATH_SEGMENT@[20; 21)
NAME_REF@[20; 21)
IDENT@[20; 21) "m"
EXCL@[21; 22) "!"
TOKEN_TREE@[22; 25)
L_PAREN@[22; 23) "("
IDENT@[23; 24) "x"
R_PAREN@[24; 25) ")"
WHITESPACE@[25; 26) " "
EQ@[26; 27) "="
WHITESPACE@[27; 28) " "