This is a FIXME issue; currently, macro invocations are parsed too eagerly. In particular, the current system decides before expansion time whether a rhs pattern-use (e.g. $y) is bound or unbound. This is incompatible with macro-producing macros that use a given identifier in a pattern position. It's also incompatible with macros inside macros, where inner binding patterns are believed to be pattern uses. The solution is to delay this decision until the macro is encountered at expansion-time, by which time all outer macros have been expanded.
Here's an example of a macro that doesn't work in the current system:
// the z flows into and out of two macros (g & f) along one path, and one (just g) along the
// other, so the result of the whole thing should be "let z_123 = 3; z_123
macro_rules! g (
($x:ident) =>
(
{macro_rules! f(
($y:ident)=>({let $y=3;$x})
);
f!($x)})
)
fn a(){g!(z)}
Trying to expand this yields this error:
Running /usr/local/bin/rustc:
/tmp/g.rs:7:12: 7:13 error: unknown macro variable `y`
/tmp/g.rs:7 ($y:ident)=>({let $y=3;$x})
^
... indicating that the $y is believed to be a use, rather than a binder.
This is a FIXME issue; currently, macro invocations are parsed too eagerly. In particular, the current system decides before expansion time whether a rhs pattern-use (e.g. $y) is bound or unbound. This is incompatible with macro-producing macros that use a given identifier in a pattern position. It's also incompatible with macros inside macros, where inner binding patterns are believed to be pattern uses. The solution is to delay this decision until the macro is encountered at expansion-time, by which time all outer macros have been expanded.
Here's an example of a macro that doesn't work in the current system:
Trying to expand this yields this error:
... indicating that the $y is believed to be a use, rather than a binder.