Could not resolve macro iproduct

[grunweg]

Thanks for your work on the project. So far, the experience of having rust-analyzer support has been a huge boon!
I just found my first rust-analyzer bug: rust-analyzer fails to resolve a trivial macro.

Minimised input

$ cat Cargo.toml
// [package] section omitted for brevity
[dependencies]
itertools = "0.9.0"
$ cat src/main.rs 
fn test(_input: &str) {}

fn main() {
    let t = ["toast", "bread"];
    use itertools::iproduct;
    for (a, b) in itertools::iproduct!(t.iter(), t.iter()) {
         test(&(a.to_string() + b));
    }
    println!("Hello, world!");
}

Expected output
rust-analyzer doesn't output any diagnostic.

Actual output
I get a diagnostic for line 6 (the one with the for loop): "could not resolve macro iproduct" (twice)

Meta information
I'm using the atom plugin with the rust-analyzer server binary; I don't think this matters.
Does not happen with the 2020-11-30 release.
Does reproduce with the 2020-12-07 release (which I just updated to; downgraded to 2020-11-30 to continue developing seamlessly).

I can try to bisect the bug, but I'm not sure how long that'd take me. (Compiling rust-analyzer takes a while on my older notebook.) Let me know if this would be helpful.

[lnicola]

Duplicate of #1165.

[flodiebold]

As an additional note, this does not happen in the 2020-11-30 release because the macro-error diagnostic was newly added. You can set "rust-analyzer.diagnostics.disabled": ["macro-error"] to hide it without having to downgrade.

[flodiebold]

Actually, @lnicola while there's a local import there, the macro is referred to with the full path, so it shouldn't matter 🤔

[lnicola]

It still seems related to the local import, since moving it to the top fixes the errors. But go to definition on the macro works -- strange.

[lnicola]

Is it an error to use a qualified macro like this? cargo check complains if I remove the use:

error: cannot find macro `iproduct` in this scope
 --> src/main.rs:5:19
  |
5 |     for (a, b) in itertools::iproduct!(t.iter(), t.iter()) {
  |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: consider importing this macro:
          itertools::iproduct
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: cannot find macro `iproduct` in this scope
 --> src/main.rs:5:19
  |
5 |     for (a, b) in itertools::iproduct!(t.iter(), t.iter()) {
  |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: consider importing this macro:
          itertools::iproduct
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 2 previous errors

[flodiebold]

Ah, the macro is written in a way that directly calls iproduct! recursively. So yeah, this is expected. You could make an issue in the itertools repository about this, but they may have some reason (backwards compatibility?) for doing this (instead of something like $crate::iproduct!).

[grunweg]

Wow, that was a quick response. (By now, I had bisected it to the emission of the diagnostic.)
Thanks for all the advice! I can confirm that moving the import to the top fixes the diagnostics issue for me.
The diagnostic emission breaks syntax highlighting for me, but I'll file a follow-up issue for that.