Change in macro hygiene on 0.6?

[rdeits]

I'm trying to understand why PyCall.jl is currently broken on Julia master: JuliaPy/PyCall.jl#332

The issue seems to be a change in the macro hygiene behavior between 0.5 and 0.6. As an example, I'll use the basic @assert macro from the metaprogramming docs

macro assert(ex)
    return :( $ex ? nothing : throw(AssertionError($(string(ex)))) )
end

function foo(x)
    @assert x == 1
end

foo(1)

On julia v0.5 this works fine. On master, I get:

± julia-0.6 macro_test.jl                                                                               16:30:58
ERROR: LoadError: UndefVarError: x not defined
 in foo(::Int64) at /Users/rdeits/locomotion/explorations/point-cloud-signed-distance/packages/v0.5/PyCall/macro_test.jl:18
 in include_from_node1(::String) at ./loading.jl:532
 in include_from_node1(::String) at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/julia/sys.dylib:?
 in include(::String) at ./sysimg.jl:14
 in include(::String) at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/julia/sys.dylib:?
 in process_options(::Base.JLOptions) at ./client.jl:271
 in _start() at ./client.jl:335
 in _start() at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/julia/sys.dylib:?
while loading /Users/rdeits/locomotion/explorations/point-cloud-signed-distance/packages/v0.5/PyCall/macro_test.jl, in expression starting on line 21

The fix is to replace $ex with $(esc(ex)). But then it's not clear why it should have worked on 0.5 but not on master. Is this a case of 0.5 being too permissive with something that was technically incorrect?

versioninfo() for my Julia master is:

Julia Version 0.6.0-dev.1556
Commit 66ba9ca (2016-12-13 11:54 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-2860QM CPU @ 2.50GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, sandybridge)

[KristofferC]

#15850

[rdeits]

I see. So it was the case that 0.5 was relying on incorrect behavior?

[yuyichao]

Yes, it's a 3yrs+ old bug that a surprisingly number of packages are relying on.

[rdeits]

Got it. Thanks! I'll see if I can put together a PR to fix PyCall.

[rdeits]

...and now I notice that @yuyichao already did that. Oh well.