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

[Stacktraces] Name of the macro instead of macro expand #35360

Open
vchuravy opened this issue Apr 4, 2020 · 2 comments
Open

[Stacktraces] Name of the macro instead of macro expand #35360

vchuravy opened this issue Apr 4, 2020 · 2 comments
Labels
compiler:lowering Syntax lowering (compiler front end, 2nd stage) error messages Better, more actionable error messages feature Indicates new feature / enhancement requests

Comments

@vchuravy
Copy link
Member

vchuravy commented Apr 4, 2020

julia> f() = @time error()
f (generic function with 1 method)

julia> f()
ERROR: 
Stacktrace:
 [1] error() at ./error.jl:42
 [2] macro expansion at ./util.jl:175 [inlined]
 [3] f() at ./REPL[2]:1
 [4] top-level scope at REPL[3]:1

Would be great if [2] could have been [2] @time expansion at ...

@vchuravy vchuravy added the feature Indicates new feature / enhancement requests label Apr 4, 2020
@c42f c42f added compiler:lowering Syntax lowering (compiler front end, 2nd stage) error messages Better, more actionable error messages labels Apr 5, 2020
@c42f
Copy link
Member

c42f commented Apr 5, 2020

I had a quick look into how to do this. Currently, the fact that a given part of the code came from a macro seems to be lost after macro expansion.

So why do you see macro expansion in the backtrace? Well, this information is re-inferred during lowering in the compile-body and compact-ir passes, but the inference is imperfect: it relies on the file name where the macro was defined being different from that of the function itself. Certainly, the exact macro name is lost by this point!

So to do this correctly is actually somewhat involved: it requires adding information to the AST which comes out of macro expansion, and correctly preserving this through the initial lowering passes. (LineNumberNode won't do the trick since it only has file and line information.)

Still, this seems directly related to what I'm working on at the moment, so it's probably something I should tackle as part of the larger frontend work I'm doing.

@c42f c42f self-assigned this Apr 5, 2020
@vtjnash
Copy link
Member

vtjnash commented Oct 27, 2022

May have been mostly implemented in #44995

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:lowering Syntax lowering (compiler front end, 2nd stage) error messages Better, more actionable error messages feature Indicates new feature / enhancement requests
Projects
None yet
Development

No branches or pull requests

3 participants