useless errors with macro in a separate crate

[durka]

TL;DR: I'm annoyed about note: this error originates in a macro outside of the current crate and want a way to turn it off and get back the error backtrace that tells me where the problem is.

I separated some of my utility code and macros into a utils crate for faster compile times. In this error, I have a macro in there rpc!, which invokes another macro, guilty!. This requires the crate that invokes rpc! to also import the crate that defines guilty!, but I forgot to do that. However, the error message gives me no way to find that out because it doesn't show where the error actually occurs within the rpc! macro:

error: macro undefined: 'guilty!'
   --> crates/back/flow/src/lib.rs:374:17
    |
374 |                 assert!(rpc!(tx, CmdFrom::Start, service.clone(), data.clone()).unwrap());
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: this error originates in a macro outside of the current crate

In this case I wrote all the crates in question. But even if I didn't, and I were going to submit a bug to the author of rpc!, there's no useful information in this error message. Can there be a way to get back the error information, either by a compiler switch or using cargo's workspace feature or something?

cc @jonathandturner

[Arnavion]

I'm not in a position to try atm, but does

#![feature(trace_macros)]

trace_macros!(true);

help?

[durka]

@Arnavion it doesn't help because you just see the expansion steps up until it looks at the body of rpc!, at which point it reports the undefined macro. trace_macros doesn't give source location information, anyway.

[durka]

This issue came up again today with a different macro crate and I'm really at a loss as to how I can possibly debug. The removal of this information, with no way to get it back, is a real low blow to macro authors.

[sophiajt]

The long-term hope here is to have macro debuggers. Since macros are still rapidly changing, I suspect it may take a little while to get to that point.

The macro backtrace is still available from the compiler, though I believe it's currently most readily available in the JSON output. Definitely not a perfect solution.

Definitely no ill-will towards macro authors.

[durka]

I share that optimism towards a future macro-expanding RLS (or something), and I know the team didn't mean to cause any trouble, but I maintain it was at least unwise to remove the backtraces before there is any other macro debugging facility available. Would a PR be considered to add a -Z all-macros-are-local?

[sophiajt]

I'd definitely consider it. cc @nikomatsakis and @nrc in case they have thoughts.

[nrc]

I would be happy to have a flag which showed macro errors in upstream crates. (I'd call it show-dep-macro-errors or something like that).

[nikomatsakis]

@durka I'd be ok with a flag. It seems like we have a collection of "crappy but useful tools for helping macro authors" (e.g., the Rust pretty printer -- maybe a few others?). I wonder if it worth trying to expose them in some way besides random -Z flags? Would we even consider stabilizing them (if not their output)?

[nikomatsakis]

@durka I'd probably call it -Z macro-backtrace or something though.

[abonander]

This error isn't helpful when trying to debug macros in examples, either. 😒