ifmt macros (using proc_macro_hack) fail to expand

[flodiebold]

I have the same issue using ifmt, which has the iwriteln! macro.

The error message is:

proc macro proc_macro_fake_call_site_iwriteln not expanded: proc macro not foundrust-analyzer

It looks like the error prints out for every usage, so 100s of times in my case.

The use statement is:

use ifmt::{iwrite, iwriteln};

After that all other use statements show errors, the repeating message above. cargo check runs with no errors.

An example usage of this macro is:

iwriteln!(code, module_header)?;

As the original report said, this used to show up sometimes and go away. Even after restarting rust-analyzer the spurious error remains.

I must say that rust-analyzer has gotten so much better recently, once you get this fixed it will be awesome.

Originally posted by @cisaacson in #12610 (comment)

[flodiebold]

I can't reproduce the proc macro not found, so maybe / hopefully this one is already fixed.

I'm running into two issues with ifmt:

iwriteln!(code, module_header)?;

gives me "unresolved import" and "unresolved macro _proc_macro_hack_iwriteln" errors. If I manually expand the macro call, it results in:

    use $crate::_proc_macro_hack_iwriteln;
    #[$crate::proc_macro_fake_call_site_iwriteln(code, module_header)]
    #[derive(_proc_macro_hack_iwriteln)]
    #[allow(dead_code)]
    enum ProcMacroHack {
        Value = ("code , module_header", 0).1,
    }
    proc_macro_call!()

and if I replace the $crate by ifmt the macro calls actually get resolved, so there might be something wrong with our resolution of $crate here?

Doing that replacement and expanding proc_macro_fake_call_site_iwriteln results in

    {
        use ifmt::_proc_macro_hack_iwriteln;
        #[derive(_proc_macro_hack_iwriteln)]
        #[allow(dead_code)]
        enum ProcMacroHack {
            Value = ("code, module_header", 0).1,
        }
        proc_macro_call!()
    };

(ignoring some span / hygiene stuff that hopefully doesn't matter in practice here); now _proc_macro_hack_iwriteln fails to expand with not implemented. Apparently this is because it instead expects

    {
        use ifmt::_proc_macro_hack_iwriteln;
        #[derive(_proc_macro_hack_iwriteln)]
        #[allow(dead_code)]
        enum ProcMacroHack {
            Value = (stringify!(code, module_header), 0).1,
        }
        proc_macro_call!()
    };

The above code then expands correctly. So this seems to be an issue with us expanding stringify too eagerly?

[flodiebold]

Oh, maybe the first one is because the iwrite! macro is generated by proc_macro_hack, so possibly we wrongly consider proc_macro_hack as the $crate?

[cisaacson]

@flodiebold Thanks very much for looking into this, if I can help with feedback please let me know.

[Veykril]

This no longer seems to error 🎉