Skip to content
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

Syntax backtraces don't work for the new macro system #3065

Closed
paulstansifer opened this issue Jul 31, 2012 · 14 comments
Closed

Syntax backtraces don't work for the new macro system #3065

paulstansifer opened this issue Jul 31, 2012 · 14 comments
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-syntaxext Area: Syntax extensions C-feature-request Category: A feature request, i.e: not implemented / a PR. P-low Low priority

Comments

@paulstansifer
Copy link
Contributor

log_syntax! should emit, in this case, information about the invocation of my_complex_macro(), but doesn't. I believe that this can be fixed by having transcribe.rs set up expn_info the way that simplext.rs does.

macro_rules! my_complex_macro {
    { } => { log_syntax!("asdf"); }
}

fn main() {
    io::println(my_complex_macro!());
}
@catamorphism
Copy link
Contributor

Not critical for 0.6, de-milestoning

@bstrie
Copy link
Contributor

bstrie commented Apr 30, 2013

What's the expected output here? Running the example gives:

⌁ rustc 3065.rs
"asdf"
3065.rs:6:16: 6:36 error: mismatched types: expected `&str` but found `()` (expected &str but found ())
3065.rs:6     io::println(my_complex_macro!());
                          ^~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

@paulstansifer
Copy link
Contributor Author

It should give a "backtrace" of errors, indicating both of the invocations that led to the error.

@catamorphism
Copy link
Contributor

Nominating for milestone 3, feature-complete

@graydon
Copy link
Contributor

graydon commented Jun 6, 2013

accepted for production-ready milestone

@catamorphism
Copy link
Contributor

(bug triage) Milestone still looks right; carry on.

@pnkfelix
Copy link
Member

we should feature-guard whatever this log-syntax thing is.

@pnkfelix
Copy link
Member

under assumption log_syntax gets feature guarded, this is accepted for P-low

@steveklabnik steveklabnik added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label Jan 21, 2015
@steveklabnik
Copy link
Member

log_syntax is now Active, but this is still a bug.

@kmcallister kmcallister added the E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. label Mar 3, 2015
@carols10cents
Copy link
Member

(Hi, I'm trying to help make E-easy issues more accessible to newcomers 😸)

I tried reproducing this and it compiles and prints "asdf". From the book chapter on macros:

log_syntax!(...) will print its arguments to standard output, at compile time, and "expand" to nothing.

This sounds like log_syntax! is behaving as expected? Unless "its arguments" is referring to the macro's arguments as opposed to log_syntax!'s arguments...?

I'm also not sure how to interpret paulstansifer's comment:

It should give a "backtrace" of errors, indicating both of the invocations that led to the error.

What error is this referring to? Which two invocations is this referring to?

Basically... is this still an issue? If so, it's sounding more like an additional feature to log_syntax!, not a bug...?

@paulstansifer
Copy link
Contributor Author

@carols10cents That's a great idea. I'm not 100% sure that this is E-Easy, as it requires some knowledge of the internals of macro expansion.

The "syntactic backtrace" is analogous to, but totally distinct from, the standard idea of a backtrace. In the following example (my original example is not great):

#![feature(log_syntax)]

macro_rules! macro_2 {
    { } => { log_syntax!("asdf"); }
}

macro_rules! macro_1 {
    { } => { macro_2!() }
}

fn main() {
    macro_1!();
}

...Rust should print out the sequence of macro invocations that led to log_syntax!() being invoked:

test.rs:4:10 asdf
...while expanding:
test.rs:8:10 macro_2!()
...while expanding:
test.rs:12:1 macro_1!()

I think that the facility for printing syntactic backtraces exists, but it's not getting the right information.

@brson brson removed the E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. label Jun 27, 2016
@brson
Copy link
Contributor

brson commented Jun 27, 2016

Not easy!

@brson
Copy link
Contributor

brson commented Jun 27, 2016

The backtrace behavior described in the op may actually be referring to trace_macros!. It seems like log_syntax purposely just stringifies ASTs and dumps them.

@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 19, 2017
@steveklabnik
Copy link
Member

Triage: this issue is so old that "new macro system" refers to the macro system that we're about to soft deprecate 😆 🤣

I'm not sure if this is something that is still relevant or will be addressed. The whole feature is describe as a "hack that is likely to be removed."

As such, I'm going to close this. RIP a four-digit issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-syntaxext Area: Syntax extensions C-feature-request Category: A feature request, i.e: not implemented / a PR. P-low Low priority
Projects
None yet
Development

No branches or pull requests

10 participants