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

macro hygiene escaping breaks let f(x)=... #20241

Open
stevengj opened this issue Jan 26, 2017 · 3 comments
Open

macro hygiene escaping breaks let f(x)=... #20241

stevengj opened this issue Jan 26, 2017 · 3 comments
Labels
bug Indicates an unexpected problem or unintended behavior compiler:lowering Syntax lowering (compiler front end, 2nd stage) macros @macros

Comments

@stevengj
Copy link
Member

stevengj commented Jan 26, 2017

julia> macro foo()
       f = esc(:f); :(let $f(x) = x; $f(3); end)
       end
@foo (macro with 1 method)

julia> @foo
ERROR: syntax: invalid function name "(escape f)"

julia> macroexpand(:(@foo))
:($(Expr(:error, "invalid function name \"(escape f)\"")))

It looks like macroexpand.scm is forgetting to unescape somewhere. @JeffBezanson, any ideas?

(I'm running into this when trying to fix a bug I found in #20164.)

@stevengj stevengj added the parser Language parsing and surface syntax label Jan 26, 2017
@stevengj
Copy link
Member Author

It might be helpful if I could print a Scheme stack trace to see the Scheme stack at the point of the error, but (print-stack-trace (stacktrace)) doesn't seem to be working... is it being intercepted somehow when flisp is running inside the Julia parser?

@stevengj
Copy link
Member Author

stevengj commented Jan 26, 2017

It looks like the error is occurring in the vars-introduced-by-patterns function. In particular, I think the problem may be that vars-introduced-by-patterns is calling julia-expand0 for let statements with functions, and julia-expand0 (normally called after macro expansion) doesn't recognize escapes.

@vtjnash vtjnash added bug Indicates an unexpected problem or unintended behavior compiler:lowering Syntax lowering (compiler front end, 2nd stage) macros @macros and removed parser Language parsing and surface syntax labels Sep 15, 2020
@vtjnash
Copy link
Member

vtjnash commented Sep 15, 2020

I think the solution here is to teach expand-forms about escape, so that we can accurately use the resolve-scopes pass (and remove this preprocessing step), instead of attempting to just handle most common patterns in the macroexpand and hoping resolve-scopes gets the same answer. As it is, it already can miss other syntax forms, or get confused by them.

aviatesk added a commit to aviatesk/JET.jl that referenced this issue Feb 21, 2021
aviatesk added a commit to aviatesk/JET.jl that referenced this issue Feb 22, 2021
aviatesk added a commit to aviatesk/JET.jl that referenced this issue Feb 23, 2021
* fixes #104

* more sensible stacktrace scrubbing

* rm no longer needed `at-noinline` annotations

* refactor stacktrace scrubbing

* add more test for stacktrace scrubbing

* circumvent JuliaLang/julia#20241, add more world-age test
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior compiler:lowering Syntax lowering (compiler front end, 2nd stage) macros @macros
Projects
None yet
Development

No branches or pull requests

2 participants