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. 😒

[durka]

Can anyone write up mentoring instructions on where to find this information in the compiler?

[durka]

Anyone who doesn't think this is worthwhile is welcome to diagnose the warning in the attached gist. Relevant macro-expanded code is provided. https://gist.github.com/durka/c4a7adb095ac76209c6e7385bfd9e3ee

[nrc]

@durka this:

rust/src/librustc_errors/emitter.rs

Line 717 in 1beaea2

fn fix_multispan_in_std_macros(&mut self, span: &mut MultiSpan) -> bool {

is where we elide the macro backtrace, I think. I'd guess you could just check the flag in there somewhere. I don't know this code in detail though, sorry.

[fschutt]

I personally wish I could just see what the code is that cargo outputs for one specific file.

If I use rustc -Z unstable-options --pretty=expanded errors.rs, I can't use any macros that are not defined in the current crate. I've tried cargo expand, it does nothing (i.e. on failure, it doesn't output the expanded file).

Like, just an option to take a my_macros.rs. I don't necessarily need a backtrace, just to write the expanded file (or the point up to which the macro could be expanded) to a .rs.expanded or stdout.

Currently, all I get is something like this:

error: no rules expected the token `TUPLE`
  --> src/errors.rs:3:1
   |
3  | / error_chain! {
4  | |     
5  | |     foreign_links {
6  | |         IoError(::std::io::Error);
...  |
28 | |     }
29 | | }
   | |_^
   |
   = note: this error originates in a macro outside of the current crate

error: aborting due to previous error

... which isn't particularly helpful.

[roblabla]

Is there still no way to do this ? I'm currently toying around with relm (which heavily relies on proc macros), and the situation is very bad there :(.