Improving macro errors

compiler
1

As part of our efforts to update error messages (which, if you’re interested you can go here to get involved), one of the things that still needs work are the macro errors. In the current version of “new format” these haven’t been updated, and still look like the old format.

This was intentional to “encourage” me to see if we can come up with a better solution.

Today, macro errors can come out of seemingly simple code, like what someone might type in a “hello world” example.

fn main() {
    println!(3 + 4);
}

Gives us:

error: expected a literal
 --> macro_error.rs:2:14
  |
2 |     println!(3 + 4);
  |              ^^^^^
<std macros>:1:23: 1:60 note: in this expansion of print! (defined in <std macros>)
macro_error.rs:2:5: 2:21 note: in this expansion of println! (defined in <std macros>)

error: aborting due to previous error

In asking around, I get the sense that relatively few people use the macro errors as they stand today. That’s not to say it doesn’t have its users, but I think we should see what the specific needs of those people are so we can address them.

Here are the issues as I see them today:

  • They’re relatively cumbersome, especially for new users
  • This is because they focus on macro writing rather than macro using
  • For macro users, they often describe unnecessary parts of the macro expansion

There are a couple directions to take, but I wanted to leave it relatively open. In general, I see:

  • We can shrink macro errors up and focus on the macro using case.
  • If we go that route, we could potentially have a “macro verbose” mode that can be enabled for macro writers
  • We can tell the macro error story a bit better using the new format
2

I definitely agree with those issues. Whenever I run into an expansion error, I have to hunt for the file/line I actually care about for longer than I’d like in the expansion backtrace. It’s particularly hard since you don’t get a snippet of that location in many cases.

3

I wonder if the compile_error macro proposed by this RFC is expressive enough for macros to write their own more user-friendly error messages.

4

A pain point for my usage of macros (and their errors) has been finding the line within the macro invocation that failed, since the current error always always points to the line with macro_name!, not where the error occurred within the multi-line macro invocation.

5

I recently thought about what if we had a middle ground to let macros warn? Having an option for custom error message would be a great addition, but in some cases we may actually not want to stop compilation.

6

+1000 for focussing on the user case by default and eliding any info about the macro + a flag for macro authors to show the macro backtrace.

1 Like
7

Just to follow up. I have a PR in review that tries to strike a balance between the macro user and the macro creator. You can read more on that thread for info (it also addresses another related macro pain point)

Worth mentioning that these fixes are just to the presentation piece. The JSON still contains the backtrace information, so macro debugging/visualization tools can use it. I’m hoping things like rustw will step in and give users an even better experience.

1 Like
8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.