Is the nested macro invocation always not expanded prior to the invocation of the outer one?

help
1

I thought the nested macro invocation is first expanded prior to the invocation of the outer one, which looks like the invocation of a function whose argument is another function invocation.

However, the following example disagree my understanding

macro_rules! enclosing_macro_expr{
    ($e:expr)=>{
       println!("{}", stringify!($e));  
    };
}
macro_rules! nested_macro{
    ($e:expr)=>{
        $e
    }
}
fn main(){
   enclosing_macro_expr!(nested_macro!(1));
}

The outcome is always nested_macro!(1) while my expected outcome is 1. I wonder what the order of the macro invocation is if one is nested in another.

If the order is always that the nested one is like a common token that will be passed to the outer one, is there any way that makes the expanded result of the nested be the argument to the outer one?

2

I don't think it's possible with declarative macro rules, as they work at syntax token trees, you can declare the kind of capture you want, but you don't have the type, and the concept similar to evaluation order is not applicable in such context, as they are not "evaluated" or "executed" in anyway, they are substitued.

in your example, the rules for enclosing-macro_expr says it want to capture a token tree of the expr kind, and a macro invocation nested_macro!(1) is of expr kind, so it is captured. after you captured it as a token tree, the only thing you do with it is substitute it in a position where such a token tree is valid, for instance, as an expression to be evaluated at runtime or an const expression, or pass it to other macros (including compiler builtin macros) that would eventually get expanded but not within the control of your macro.

I think you need to use procedural macros in such cases, though I am not an expert on macros, I might be wrong on this.

3

I think you need to use procedural macros in such cases, though I am not an expert on macros, I might be wrong on this.

The macro invocation as a argument of procedural macros is still not expanded first.

4

that is true, but at least your procedural macro can transform the token stream in ways declarative macros can't. basically, you write your own macro expansion.

5

well, as a second thought, I don't think you can achieve what you described in the original post; unlike the lisp family languages like clojure, I don't think anything similar to macroexpand-1 exists in rust. I'd be happy if I was wrong though.