really bad error messages for trying to `use` a macro from a module

[durka]

If you read up on new-style macro imports in the edition guide and miss the tiny note that it doesn't work for macros in modules in your own crate (why not?!), you might try this:

mod has_a_macro {
    macro_rules! a_macro { () => {} }
}

use crate::has_a_macro::a_macro;

fn main() {
    a_macro!();
}

BIG MISTAKE.

error[E0432]: unresolved import `crate::has_a_macro::a_macro`
 --> src/main.rs:6:5
  |
6 | use crate::has_a_macro::a_macro;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `a_macro` in `has_a_macro`

error: cannot determine resolution for the macro `a_macro`
 --> src/main.rs:8:5
  |
8 |     a_macro!();
  |     ^^^^^^^
  |
  = note: import resolution is stuck, try simplifying macro imports

error: aborting due to 2 previous errors

OK, two errors here, neither of which are helpful.

The first one simply says the macro doesn't exist when it obviously does, this is just the compiler gaslighting the user. Next!

The second one is fairly hilarious (this is already the simplest situation possible) and unactionable.

Let's see... I know that in the past you used to put #[macro_use] above the mod declaration to do this. Adding that nets a different second error:

error[E0659]: `a_macro` is ambiguous (`macro_rules` vs non-`macro_rules` from other module)
 --> src/main.rs:9:5
  |
9 |     a_macro!();
  |     ^^^^^^^ ambiguous name
  |
note: `a_macro` could refer to the macro defined here
 --> src/main.rs:3:5
  |
3 |     macro_rules! a_macro { () => {} }
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: `a_macro` could also refer to the unresolved item imported here
 --> src/main.rs:6:5
  |
6 | use crate::has_a_macro::a_macro;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = help: use `crate::a_macro` to refer to this unresolved item unambiguously

This is... really confusing. I can see that the compiler knows exactly which macro I want to call, but it refuses to do it, and for some reason it says it's ambiguous with the statement trying to import it. The `macro_rules` vs non-`macro_rules` word salad doesn't help matters.

Also, the suggestion doesn't work, you just get the original import resolution is stuck error back.

So, the eventual solution is to remove the use statement, leaving only #[macro_use], but this isn't discoverable from the mess of errors. Can we take off the compiler-colored glasses and make better diagnostics for this situation? I can't imagine I'm the only person who tried this.

[petrochenkov]

Can we take off the compiler-colored glasses and make better diagnostics for this situation?

Well, at least with compiler-colored glasses all the errors are correct and make sense.

Possible improvements:

• Suggest #[macro_use] if module has_a_macro in unresolved has_a_macro::a_macro has a non-modularized macro.
• Do not report the macro/import resolution deadlock error ("cannot determine resolution") if there are other errors? Not sure, this one can make things worse.
• Somehow guess what caused the deadlock. I'm not sure it's generally possible to do without too much effort, but at least one case is known to be common - blocking single import, so we can try to do something with it. Also say "deadlock" in the message explicitly?

[jonhoo]

As an addendum to this, this problem gets even weirder if has_a_macro has a submodule that is specifically in a different file, and which wants to call a_macro. Then, the macro has to be declared #[macro_export] (even though it won't be exported across crate boundaries), and the use in the submodule has to be use crate::a_macro. Neither super::a_macro nor crate::has_a_macro::a_macro will work. This is the only way to get that setup to work as far as I could tell. You also then no longer need the #[macro_use]...

[Herschel]

I was also bit by this and was clueless about the error until googling. The surprising part is that the macro was working fine for quite some time without any #[macro_use] or #[macro_export] but then I reshuffled some modules, and the macro broke as above.

I had to follow @jonhoo's instructions of using #[macro_export] and then use crate::a_macro; from the crate root.

[mimoo]

ended up here to understand that I had to remove the use path::macro to get rid of the error, thanks! For some reason, macro is accessible without a use

[lmapii]

I've also stumbled upon this and then found an answer on stack overflow that wasn't working at all: https://stackoverflow.com/a/31749071/7281683

It says that the #[macro_use] is the "old method" and proposes a solution that wasn't working for me either. I kept the #[macro_use] but I'm not really happy with it. Also the linked book is outdated and should be updated to https://veykril.github.io/tlborm/ ?

[arbaregni]

I solved this by copy-pasting 💀

[gxxcastillo]

For any other noobs like myself: I was getting "Import resolution is stuck, try simplifying macro imports" and my fix was to move my dependency declaration in the Cargo.toml file from [dev-dependencies] and into [dependencies].