Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upTracking issue for `log_syntax`, `trace_macros` #29598
Comments
aturon
added
T-lang
B-unstable
labels
Nov 5, 2015
aturon
changed the title
Tracking issue for `log_syntax`
Tracking issue for `log_syntax`, `trace_macros`
Nov 5, 2015
This comment has been minimized.
This comment has been minimized.
|
Does anybody care about either of these at all anymore? They are ancient debugging tools that seem unlikely to be stabilized without serious rethinking. Can we remove them? cc #3065 |
This comment has been minimized.
This comment has been minimized.
|
f? @rust-lang/compiler |
This comment has been minimized.
This comment has been minimized.
|
@durka says not to remove |
This comment has been minimized.
This comment has been minimized.
|
I realize it's a hack, but it's pretty much impossible to debug complex macros without using the trace functionality. As of now it's accessible both by the |
This comment has been minimized.
This comment has been minimized.
|
I used It’s only useful temporarily to see what’s going on, IMO never something I’d want to commit in git. So a command-line option instead of syntax extension would be ok (even slightly better) as long as how to use it with Cargo is documented in https://doc.rust-lang.org/book/macros.html#debugging-macro-code ( |
This comment has been minimized.
This comment has been minimized.
|
The problem with the switch is that it turns it on for everything. Due to the way it's output is formatted (spread across multiple lines), this can make debugging a badly behaving macro in the midst of lots of other macro expansions completely hellish. If we could keep only one, I'd keep And just to reiterate what durka said: this is, indeed, one of the very, very few tools we have to debug macros. It's not very good, but it's not like there's really any alternative. |
This comment has been minimized.
This comment has been minimized.
|
Can we deprecate |
This comment has been minimized.
This comment has been minimized.
|
I'm not sure what macro_rules! some_broken_macro {
(...) => {
struct $whatever { $($foo: $bar),* }
// Let's say this causes a compile error for some reason, so macro expansion never finishes.
// To debug, I could wrap the macro output in log_syntax!(...) to see what it would output.
}
}I use |
This comment has been minimized.
This comment has been minimized.
|
I was going to comment on this tracking issue a couple weeks back around when I made this issue, but I guess I eventually decided against it. Perhaps I wanted to give it more time to develop since the new format was so recent. In any case, I have not been enjoying the new format. I can't say that I've ever needed a debugging tool to see what a macro expanded into; in all of my time debugging macros, it has been easy enough to figure out the issue based simply on what it was expanded from. But now these two types of information are all tangled together into one giant bowl of spaghetti with hardly any visual cue to help my eyes pull them apart. Frankly, the zig-zagging shape formed by the note headers is making me dizzy! new output (nightly)
old output (nightly-2017-03-01)
The old output was chaotic, but at least it tells a story. You can read the There is a note about this with plans to eliminate redundant "expanding" lines, but I am suspicious as to whether that is enough to make the output comprehensible. |
This comment has been minimized.
This comment has been minimized.
|
I see the motivating issue here but to me it would have seemed sufficient to just fix the misleading "expands to" to "expanding". Is there a home-run example of a problem that would be difficult to debug without the added information of what a macro expanded into? cc @jorendorff |
This comment has been minimized.
This comment has been minimized.
|
I've certainly wanted to see expansion results though I don't have a
specific example. I think the answer here may lie in "--error-format json"
and some tool that presents the info in an actually readable way.
…On Tue, Jul 4, 2017 at 7:20 PM, Michael Lamparski ***@***.***> wrote:
I see the motivating issue here
<#42072> but to me it would have
seemed sufficient to just fix the misleading "expands to" to "expanding".
Is there a real home-run example of a problem that would be difficult to
debug without the added information of what a macro expanded into?
cc @jordendorff
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#29598 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAC3n4-4ZiLkpnbTZPQycCycqXnNCREWks5sKsi-gaJpZM4GcPa8>
.
|
This comment has been minimized.
This comment has been minimized.
I don't know if it's a "home run", but I'll give an example. First some background. There are two cases where I think the output is helpful:
Now my example. Once in a while I write |
This comment has been minimized.
This comment has been minimized.
|
There are definitely some things in the |
This comment has been minimized.
This comment has been minimized.
|
I have often wanted both the inputs/outputs as well, no question. Not to say that the current output is the easiest to parse. |
aturon commentedNov 5, 2015
The
log_syntaxfeature gate allows use of thelog_syntaxmacro attribute, and similarly fortrace_macros. Both are "nasty hacks that will certainly be removed" (according to the reference manual).