Skip to content

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

Closed

Description

@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.

Activity

  1. michaelwoerister commented on Apr 3, 2017

    @michaelwoerister
    Member

    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:

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

  2. michaelwoerister commented on Apr 10, 2017

    @michaelwoerister
    Member

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

  3. self-assigned this
    on Apr 24, 2017
  4. jseyfried commented on Apr 24, 2017

    @jseyfried
    Contributor

    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.

  5. SimonSapin commented on Apr 24, 2017

    @SimonSapin
    ContributorAuthor

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

  6. michaelwoerister commented on Apr 24, 2017

    @michaelwoerister
    Member

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

  7. michaelwoerister commented on Apr 24, 2017

    @michaelwoerister
    Member

    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?

  8. jseyfried commented on Apr 24, 2017

    @jseyfried
    Contributor

    @michaelwoerister
    Once #40939 lands it should be simple.

  9. rushmorem commented on Apr 26, 2017

    @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
  10. seanmonstar commented on Jun 7, 2017

    @seanmonstar
    Contributor

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

  11. michaelwoerister commented on Jun 8, 2017

    @michaelwoerister
    Member

    @jseyfried Is there an ETA for #40939?

  12. michaelwoerister commented on Jul 7, 2017

    @michaelwoerister
    Member

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

  13. jseyfried commented on Jul 10, 2017

    @jseyfried
    Contributor

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

  14. michaelwoerister commented on Jul 11, 2017

    @michaelwoerister
    Member

    Thanks a lot, @jseyfried ❤️

  15. added a commit that references this issue on Jul 18, 2017
  16. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Aug 16, 2017
  17. nikomatsakis commented on Aug 16, 2017

    @nikomatsakis
    Contributor

    @jseyfried any updates on status of this?

  18. alexcrichton commented on Sep 15, 2017

    @alexcrichton
    Member

    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!

  19. added a commit that references this issue on Sep 19, 2017
    0694e4f
  20. added a commit that references this issue on Sep 19, 2017
    5d5dcae
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-incr-compArea: Incremental compilationC-enhancementCategory: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions