Rust passes invalid syntax to procedural macros when expanding other macros

[PlasmaPower]

Here's an example of the issue: https://play.rust-lang.org/?gist=1fcdc0a76f5c4dd0f2da855e497ea298&version=stable

In that code I use #[doc=$doc], which is expanded to invalid syntax #[doc=concat!("Hello", "world", "!")] before being passed to the serde Deserialize procedural macro.

This uses the same expansion as #42164

[abonander]

I believe that this should be resolved by #48465.

[eddyb]

macro_rules! foo {
    ($x:expr) => {
        #[export_name = $x] pub fn foo() {}
    }
}

foo!(concat!("ma", "in"));

// Errors about `concat!` not being parseable.
// #[export_name = concat!("ma", "in")] pub fn foo() {}

fn main() {}

This showcases that we actually expand macro invocations within a NtExpr which was probably never intended. Are attributes the only place where we embed a TokenStream like that?

Should we just support macro invocations in attributes at the top-level and expanding them?
There's probably a good reason to avoid expanding macros nested arbitrarily just because it went through $x:expr in a macro_rules, but it needs some discussion.

cc @rust-lang/compiler @jseyfried @petrochenkov

[durka]

Look at that, eager expansion!

Should we just support macro invocations in attributes at the top-level and expanding them?

Yes please!

[eddyb]

@durka It's not eager! The invocation stays in there until macro expansion reaches it accidentally-ish.

[nikomatsakis]

I'm going to remove the I-nominated tag. We're not prioritzing this, but I agree with @alexcrichton that this is something we ought to "figure out' as part of macros 1.2 etc.

[durka]

Maybe change the title to "Rethink proc macro expansion order" or something?

[petrochenkov]

I'll close this in favor of #55414 where the discussion regarding cases like this case is happening.