Macro invocation Error for simple dbg macro

[edwin0cheng]

The following code shows an error of "failed to parse or resolve macro invocation" in master bb69772

fn main() {
    dbg!("test");
}

[edwin0cheng]

In more recent code (b988c6f), the errors are more explicit :

could not resolve macro `$crate::file`
could not resolve macro `$crate::line`
could not resolve macro `$crate::stringify`

It seem like we couldn't resolve the $crate here.

[0x7CFE]

In my case the issue also causes error flood in seemingly unrelated parts of the source file. For example, somewhere in the source I can have the following lines:

let longs: HashSet<BitVector> = offset_codes.iter().cloned().collect();
let shorts: HashSet<BitVector> = offset_codes.iter().map(|&b| contexts::hash(&[(b, 0.into())])).collect();
dbg!(longs.len(), shorts.len());

And it causes the following errors within the same file:

P.S.: If I comment the dbg! line all errors disappear.

[villem]

Exactly same thing happens to me with the latest nightly
INFO [12/6/2020, 10:16:45 AM]: PersistentState: {
lastCheck: 1607242597294,
releaseId: 34886999,
serverVersion: '0.3.405-nightly'
}
INFO [12/6/2020, 10:16:51 AM]: Using server binary at /Users/.../Library/Application Support/Code/User/globalStorage/matklad.rust-analyzer/rust-analyzer-mac

Commenting out dbg! removes the errors.

[Heliozoa]

I started getting this error after I updated to 0.2.408. Reverting to 0.2.400 fixes the issue. In addition to dbg!, usage of assert_eq! with a message seemed to cause this as well. I'm on Ubuntu 20.04.1 LTS and vscode

Version: 1.51.1
Commit: e5a624b788d92b8d34d1392e4c4d9789406efe8f
Date: 2020-11-10T23:31:29.624Z
Electron: 9.3.3
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Linux x64 5.4.0-56-generic

if that's of any interest.

[doivosevic]

Version: 1.51.1 (system setup)
Commit: e5a624b788d92b8d34d1392e4c4d9789406efe8f
Date: 2020-11-10T23:34:32.027Z
Electron: 9.3.3
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Windows_NT x64 10.0.18363

Same thing for me. Started happening today out of nowhere, even after the latest update. I think adding another #[test(cfg)] triggered this but cannot verify. I comment out the code but the error appears in other files. I only appears in open files. Commenting out other code does not help. The error appears in remaining files

EDIT: One important thing to note I think is that I'm using Remote-SSH from windows to ubuntu. I cannot as of yet repro this locally on the same code

[unbornchikken]

Just wanted to confirm the above reports. I have issues by using 0.2.408 with genawaiter macros on Windows. Reverting back to 0.2.400 resolved the issue.

[lnicola]

The warning can be disabled using:

"rust-analyzer.diagnostics.disabled": [
  "macro-error"
]

At this point there's no need for more confirmations.

[jonas-schievink]

The issue is that path resolution only looks at non-legacy macros, but $crate::m can also refer to legacy macros. No, doesn't seem to be the problem.

[jonas-schievink]

ModPath { kind: Plain, segments: [Name(Text("$crate")), Name(Text("arg"))] } 🤔

Reproduction:

#[macro_export]
#[rustc_builtin_macro]
macro_rules! format_args {}

#[macro_export]
macro_rules! arg {}

#[macro_export]
macro_rules! outer {
    () => {
        $crate::format_args!( "", $crate::arg!() )
    };
}

fn f() {
    outer!();
  //^^^^^^^^ could not resolve macro `$crate::arg`
}

[jonas-schievink]

The resolution error should now be fixed. I'll look into the misplaced diagnostics later.

[danieljl]

Thanks @jonas-schievink! Is a new hotfix version going to be released? Or will this fix only be released on the next weekly release (6 days from now)?

[lnicola]

You can use the nightly version, but I'd suggest manually replacing the LSP binary or waiting until tomorrow because of a Code extension bug related to the update functionality (#6757).

Or you could disable the warning.

[jonas-schievink]

(the misplaced diagnostics are now also fixed)

[jeromegn]

The misplaced diagnostics are now gone, but I still get a "failed to parse macro invocation" error with the latest nightly. This is doing a tokio::pin! invocation.

[Victor-Savu]

Same as @jeromegn , I am still getting the error on the nightly version of rust-analyzer, in my case in a call to futures::try_join!.

[msrd0]

I just compiled the rust-analyzer-git package on ArchLinux, but I'm still seeing failed to parse macro invocation for my invocation of the serde_json::json! macro.

[ibraheemdev]

Was this fixed with the latest stable release?

[msrd0]

Nope, still the same error message on the stable from yesterday.

[villem]

This is much better now, but I get "unresolved import" error when with use derive_more::Display;
I'm using the latest nightly as of Dec 20.

[lnicola]

@villem that's a different issue. derive_more seems to be using a proc macro attribute, and those aren't supported yet (#6029).

Of course, you can still disable the diagnostic.

[villem]

@lnicola ok. This warning appeared in few days nightly build back. Maybe last week, so I got confused.
I'll probably disable the warning for now.