Macro matching is incorrect for macros invoked in macro expansions

[reem]

Example: http://is.gd/y5Wa67

This example should print "Type::Byte" but instead prints "Type::Struct". Calling ty_to_type! directly on u8 works, as does having forwards! receive a tt rather than a ty.

[bluss]

isn't this a feature too? I have macros where I don't want to risk that a user-supplied parameter matches such a “literal” parameter that you have in ‘bool’ etc in your example.

[michaelsproul]

I think the current behaviour makes sense - once you've matched u8 as a type its token represents that type and not the string "u8" any more.

[steveklabnik]

@rust-lang/lang , is this a bug or not?

[eddyb]

cc @jseyfried

[nikomatsakis]

Personally, I consider this a bug, but it may not be a bug we want to fix in the existing macros because of backwards compat. I've never liked how macros insert "pseudo-tokens" representing parsed entities -- although I understand the original motivation, which was to avoid the performance cost of re-parsing things over and over. I just think it should be an optimization, and not something that has visible effects on the behavior of the code.

(But all that said, it can't be as simple as "paste the tokens $foo where it appears". For example, if you have $l:expr and you do $l * $l, and $l = x + y, I would not want that to parse as x + (y * x) + y. So it seems like my mental model is that the tokens for $l are "pasted" in but inside a synthetic token tree of some kind.)

[steveklabnik]

Triage: not any changes here. Per niko's last comment, I am guessing this is a WONTFIX, especially given that nobody else other than the original reporter has commented here, really. I'm gonna give this one a close for now, please let me know if this is still useful to track.