-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Tracking issue for log_syntax
, trace_macros
#29598
Comments
log_syntax
log_syntax
, trace_macros
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 |
f? @rust-lang/compiler |
@durka says not to remove |
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 |
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 ( |
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. |
Can we deprecate |
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 |
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. |
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 |
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>
.
|
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 |
There are definitely some things in the |
I have often wanted both the inputs/outputs as well, no question. Not to say that the current output is the easiest to parse. |
Triage: I'm not aware of any movement on this feature, neither to remove, fix up, nor stabilize. |
It seems this would be covered by rust-lang/rust-analyzer#5949 |
From today's @rust-lang/lang meeting: |
The
log_syntax
feature gate allows use of thelog_syntax
macro attribute, and similarly fortrace_macros
. Both are "nasty hacks that will certainly be removed" (according to the reference manual).The text was updated successfully, but these errors were encountered: