-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
new trace_macros doesn't work if there's an error during expansion #43493
Comments
Nominating for prioritization. Seems good to fix since this is very painful for macro authors. |
I think the output provided by #41520/#42103 is fine (modulo the verbosity issue #42223). It just needs to show up even when expansion doesn't finish due to an error. Something like this:
This is probably also the issue in #42170. |
This underlying issue here is that macro errors cause aborts way too much. For a quick fix, we could make sure we always call |
I think that @jseyfried's solution would be correct one. |
…ried Fix "new trace_macros doesn't work if there's an error during expansion" Fixes rust-lang#43493
…ried Fix "new trace_macros doesn't work if there's an error during expansion" Fixes rust-lang#43493
…ried Fix "new trace_macros doesn't work if there's an error during expansion" Fixes rust-lang#43493
The new trace_macros has much better output, but it has regressed in functionality! The old trace_macros could be used to debug macro expansion. Example using rustc 1.6.0:
OK, you can see
m!(foo)
was invoked, and then it didn't match so there's an error.Now with current rustc (all channels):
You no longer get to see the chain of expansions leading up to the error. This typically occurs much deeper in a string of recursive macros, making debugging much harder.
cc #41520 @estebank @nikomatsakis
The text was updated successfully, but these errors were encountered: