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

scoping/escaping bug in @cfunction #565

Closed
stevengj opened this issue Jun 6, 2018 · 3 comments
Closed

scoping/escaping bug in @cfunction #565

stevengj opened this issue Jun 6, 2018 · 3 comments
Labels

Comments

@stevengj
Copy link
Member

stevengj commented Jun 6, 2018

The Compat.@cfunction macro (#553) seems to have an escaping or scoping bug of some kind that prevents it from being used in a function. For example:

julia> using Compat

julia> foo(x) = x+1
foo (generic function with 1 method)

julia> bar() = @cfunction(foo, Int, (Int,))
bar (generic function with 1 method)

julia> bar()
ERROR: UndefVarError: foo not defined
Stacktrace:
 [1] bar() at ./REPL[3]:1

julia> baz() = cfunction(foo, Int, Tuple{Int})
baz (generic function with 1 method)

julia> baz()
Ptr{Void} @0x0000000121a79f50

cc @ararslan .

@stevengj stevengj added the bug label Jun 6, 2018
@stevengj
Copy link
Member Author

stevengj commented Jun 6, 2018

It seems to be an escaping bug. Adding an esc call fixes the problem:

@static if !isdefined(Base, Symbol("@cfunction"))
    macro cfunction(f, rt, tup)
        :(Base.cfunction($(esc(f)), $rt, Tuple{$tup...}))
    end
    export @cfunction
end

I don't really understand why the esc is needed here since the first argument of cfunction is not being written to, but maybe cfunction is magic in some way?

@stevengj
Copy link
Member Author

stevengj commented Jun 6, 2018

Looks like the other arguments need to be escaped too: :(Base.cfunction($(esc(f)), $(esc(rt)), Tuple{$(esc(tup))...}))

@yuyichao
Copy link
Contributor

yuyichao commented Jun 6, 2018

esc is needed for ALL user inputs, doesn't matter if they are written to or not. Unescaped symbols will always be interpreted as belonging to the scope of the macro. Ones that are written to will be interpreted as local variable of the macro and symbols that are not written to will be interpreted as global variable in the scope of the macro.

stevengj added a commit that referenced this issue Jun 6, 2018
(Not 0.67.1 because I accidentally tagged that without updating the TOML file.)   This fixes #565, which I need to update ZMQ.jl.
stevengj added a commit that referenced this issue Jun 6, 2018
stevengj added a commit that referenced this issue Jun 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants