Support nested macro_rules!
#34925
Support nested macro_rules!
#34925
Conversation
| @@ -2663,7 +2665,7 @@ impl<'a> Parser<'a> { | |||
| } | |||
|
|
|||
| pub fn check_unknown_macro_variable(&mut self) { | |||
| if self.quote_depth == 0 { | |||
| if self.quote_depth == 0 && !self.parsing_token_tree { | |||
There was a problem hiding this comment.
I believe quote_depth and parsing_token_tree have the exact same intended function.
There was a problem hiding this comment.
I tried just using quote_depth and it caused other problems.
There was a problem hiding this comment.
Specifically, it caused problems with parsing the left hand side of a macro_rules! body. I didn't look into it in too much detail since I wanted to do this PR as simply as possible.
There was a problem hiding this comment.
Could we remove quote_depth then?
There was a problem hiding this comment.
I don't think so -- looking into it some more, the problem is that this condition needs to be false when parsing the lhs of a macro_rules! body.
There was a problem hiding this comment.
It's always false because quote_depth is never anything other than 0.
EDIT: Oops, the modifications to quote_depth are in another module.
IMO, the whole distinction between $ ident (two tokens) and $ident (one token) is unnecessary and only creates complications.
There was a problem hiding this comment.
Agreed (out of the scope of this PR, though).
There was a problem hiding this comment.
Removed quote_depth and parsing_token_tree in #39419.
|
cc @nrc |
|
@bors r+ |
|
📌 Commit 485e2df has been approved by |
|
⌛ Testing commit 485e2df with merge c3f1268... |
|
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
|
@bors: retry On Tue, Jul 19, 2016 at 9:40 PM, bors notifications@github.com wrote:
|
|
⌛ Testing commit 485e2df with merge f83586d... |
|
💔 Test failed - auto-linux-64-cargotest |
|
@bors: retry On Wed, Jul 20, 2016 at 5:58 PM, bors notifications@github.com wrote:
|
|
⌛ Testing commit 485e2df with merge d62bb9d... |
|
💔 Test failed - auto-win-gnu-32-opt |
|
@bors: retry sorry for the number of retries... On Thu, Jul 21, 2016 at 12:37 PM, bors notifications@github.com wrote:
|
|
⌛ Testing commit 485e2df with merge 8445fd4... |
|
💔 Test failed - auto-win-gnu-32-opt |
|
@bors: retry On Fri, Jul 22, 2016 at 4:13 PM, bors notifications@github.com wrote:
|
|
Amazing. This is kinda funny though... macro_rules! outer {
($b:tt $c:ident) => {
macro_rules! inner {
($a $b $c) => { }
}
}
}
outer!(: ident); // NB: must be `:`
inner!(foo); |
|
This has added a deadlock: macro_rules! outer {
($b:tt) => {
macro_rules! inner {
($b) => { }
}
}
}
outer!($a); // OK
outer!($b); // hangs the compiler |
|
@durka Thanks, I'll look into |
|
It's not a compiler NOTE, I meant if you don't pass |
|
@durka I think that has to do with how we parse |
|
It can't be in all cases, since I passed in the |
|
I fixed the deadlock in #35453. |
macros: Make metavariables hygienic
This PR makes metavariables hygienic. For example, consider:
```rust
macro_rules! foo {
($x:tt) => { // Suppose that this token tree argument is always a metavariable.
macro_rules! bar { ($x:expr, $y:expr) => { ($x, $y) } }
}
}
fn main() {
foo!($z); // This currently compiles.
foo!($y); // This is an error today but compiles after this PR.
}
```
Today, the `macro_rules! bar { ... }` definition is only valid when the metavariable passed to `foo` is not `$y` (since it unhygienically conflicts with the `$y` in the definition of `bar`) or `$x` (c.f. #35450).
After this PR, the definition of `bar` is always valid (and `bar!(a, b)` always expands to `(a, b)` as expected).
This can break code that was allowed in #34925 (landed two weeks ago). For example,
```rust
macro_rules! outer {
($t:tt) => {
macro_rules! inner { ($i:item) => { $t } }
}
}
outer!($i); // This `$i` should not interact with the `$i` in the definition of `inner!`.
inner!(fn main() {}); // After this PR, this is an error ("unknown macro variable `i`").
```
Due to the severe limitations on nested `macro_rules!` before #34925, this is not a breaking change for stable/beta.
Fixes #35450.
r? @nrc
Fixes #6994.
r? @eddyb