3

我见过的多个例子表明这应该是可能的，但显然不是：

lib.rs：

#![feature(trace_macros)]

#[macro_export]
macro_rules! inner_macro (
    (f32) => {"float"};
);

#[macro_export]
macro_rules! outer_macro {
    ($T:ty) => {
        inner_macro!($T)
    }
}

#[cfg(test)]
mod tests {

    #[test]
    fn test_nested() {
        trace_macros!(true);
        s1: String = String::from(outer_macro!(f32));
        s2: String = String::from(inner_macro!(f32));
        trace_macros!(false);
    }
}

运行cargo test给出以下输出：

error: no rules expected the token `f32`
  --> src/lib.rs:11:22
   |
4  | / macro_rules! inner_macro (
5  | |     (f32) => {"float"};
6  | | );
   | |__- when calling this macro
...
11 |           inner_macro!($T)
   |                        ^^ no rules expected the token `f32`
...
21 |           s1: String = String::from(outer_macro!(f32));
   |                                     ----------------- in this macro invocation

这很令人困惑，因为似乎有一条规则需要 token f32。

这两个宏的扩展轨迹也有注释。第一个不起作用：

= note: expanding `outer_macro! { f32 }`
= note: to `inner_macro ! ( f32 )`
= note: expanding `inner_macro! { f32 }`

而第二个是：

= note: expanding `inner_macro! { f32 }`
= note: to `"float"`

为什么第一次扩展inner_macro!失败，而当它没有嵌套在另一个宏中时，完全相同的扩展成功？

编辑：如果我们手动执行替换，它会起作用并给出预期的输出：

macro_rules! unknown {
    ($T:ty) => {
        inner_macro!(f32)
    }
}
4

1 回答 1

3

经过更多阅读，事实证明这是一个典型的绊脚石。第一次被捕获后，获取AST Node$T的值。替换不会取代令牌，它将取代那个 AST 节点。所以我期望是这样的：$T

inner_macro!(`f32` [token])

实际上是

inner_macro!(<Type>f32</Type>)

不幸的是，对于用户来说，这两个调用都以相同的方式被字符串化为inner_macro! ( f32 ).

这样做的正确方法是将要替换的令牌捕获为“令牌树”：

macro_rules! unknown {
    ($T:tt) => {
        inner_macro!($T)
    }
}
于 2018-11-23T16:36:47.103 回答