Consider pass macro invocation arguments as AST instead of TokenTree

[edwardw]

That way, more sophisticated and precise transformation can be performed against AST before being passed into macro definitions. The main use case right now would be hygiene let bindings and loop labels.

Is this doable?

cc #12262 #10607 #12338

[sfackler]

The macro invocation syntax is almost entirely freeform. I'm not sure how much more parsing can be done while still supporting stuff like

let map = make_map!(Hey, dude! This map should have type collections::HashMap. 
                    It contains mappings "a" => 1, "b" => 2, "c" => 3);

[pnkfelix]

cc me.

[edwardw]

I don't know. My hunch is since it is parsed inside macro definition anyway, we should be able to do something at the invocation site as well.

[huonw]

Macros can also be passed many different AST nodes, like an expression, an item, an ident, a block, a pattern, etc. etc., and there's no way to tell which the macro wants without knowing the definition of the macro (i.e. intertwining parsing and macro expansion, which is a strong negative in my mind).

And it's not necessarily "obvious" what a macro wants from the definition, e.g. a procedural macro written in Rust may change what it wants to be fed in non-obvious ways.

[jbclements]

Yes, the point of macros is that you don't parse before the macro has had a crack at it. That's an important property of the MTWT model. I move that we close this issue.

[steveklabnik]

Yes, I think this can be closed. This would need an RFC today, and I'm not even sure it's what we would want.