warning: Quasi-quoting might make incremental compilation very inefficient: NtIdent(..)

[SimonSapin]

I have a macro like this:

#[macro_export]
macro_rules! define_proc_macros {
    (
        $(
            $( #[$attr:meta] )*
            pub fn $proc_macro_name: ident ($input: ident : &str) -> String
            $body: block
        )+
    ) => {
        $(
            $( #[$attr] )*
            #[proc_macro_derive($proc_macro_name)]
            pub fn $proc_macro_name(derive_input: ::proc_macro::TokenStream)
                                    -> ::proc_macro::TokenStream {
                let $input = derive_input.to_string();
                let $input = $crate::_extract_input(&$input);
                $body.parse().unwrap()
            }
        )+
    }
}

pub fn _extract_input(derive_input: &str) -> &str {
    // …
}

When I use it, I get the warning in the title twice for every generated functions. When I move things into one crate to avoid "note: this error originates in a macro outside of the current crate", the span of the warning is on $proc_macro_name in #[proc_macro_derive($proc_macro_name)].

Steps to reproduce: runCARGO_INCREMENTAL=1 cargo +nightly build -p cssparser-macros in https://github.com/servo/rust-cssparser/.

I don’t understand this warning and what I can do about it. What does quasi-quoting mean in this context? How bad is the inefficiency really? Is it possible to fix it while keeping this macro’s flexibility?

CC @michaelwoerister and @nikomatsakis for #37787 that added this warning.

[michaelwoerister]

That's strange. @jseyfried, do you see anything in the macro above that in a Token::Interpolated?
This is where the warning is generated by the way:

rust/src/librustc_incremental/calculate_svh/svh_visitor.rs

Line 1068 in 5309a3e

token::Token::Interpolated(ref non_terminal) => {

[michaelwoerister]

ping @jseyfried: Do you know what could be going on here? Where does the macro definition above introduce a Token::Interpolated?

[jseyfried]

The $proc_macro_name turns into a Nonterminal::Ident token. Normally, nonterminals are parsed into AST and don't cause warnings. However, now that #40346 has landed, attributes can have arbitrary tokens and the Nonterminal::Ident token ends up in the final AST/HIR.

I believe the solution here is to expand interpolated/nonterminal tokens into their underlying terminal tokens as we lower to HIR.

[SimonSapin]

@jseyfried If I understand correctly, something is inefficient but what needs to change to fix it is in rustc rather than in my code?

[michaelwoerister]

@SimonSapin That is correct. It's an inefficiency in rustc's handling of some parts of the HIR/AST.

[michaelwoerister]

I believe the solution here is to expand interpolated/nonterminal tokens into their underlying terminal tokens as we lower to HIR.

@jseyfried, that sounds like a great solution. Would that be much work?

[jseyfried]

@michaelwoerister
Once #40939 lands it should be simple.

[rushmorem]

I'm getting this warning too when using proc-macro-hack (cc @dtolnay). Is there any way to suppress it?

warning: Quasi-quoting might make incremental compilation very inefficient: NtIdent(..)
  --> derive/src/lib.rs:9:1
   |
9  |   proc_macro_expr_impl! {
   |  _^ starting here...
10 | |     pub fn args_impl(input: &str) -> String {
11 | |         args::Args::new(input)
12 | |             .process().tokens
13 | |             .to_string()
14 | |     }
15 | | }
   | |_^ ...ending here
   |
   = note: this error originates in a macro outside of the current crate

[seanmonstar]

If it will take a while to fix this, it would be nice to at least be able to suppress the warning.

[michaelwoerister]

@jseyfried Is there an ETA for #40939?

[michaelwoerister]

Now that #40939 has landed, will you look into a fix, @jseyfried?

[jseyfried]

@michaelwoerister Sure, I still think #40946 (comment) is the best fix; I'll implement this week.

[michaelwoerister]

Thanks a lot, @jseyfried ❤️

[nikomatsakis]

@jseyfried any updates on status of this?

[alexcrichton]

I've made a PR for this at #44601, although @jseyfried if that's not at all what you were thinking, just let me know!