PyCall.PyJlError has no field msg

[lgeissbauer-btig]

julia> JET.@report_call pyimport("snowflake.connector")
═════ 2 possible errors found ═════
┌ @ C:\.julia\packages\PyCall\9Nvls\src\PyCall.jl:556 e.msg
│┌ @ Base.jl:38 Base.getfield(x, f)
││ type PyCall.PyJlError has no field msg
│└──────────────
┌ @ C:\.julia\packages\PyCall\9Nvls\src\PyCall.jl:556 e = PyCall.pyerror(PyCall.string(e.msg, "\n\n", msg, "\n"), e)
│ no matching method found `pyerror(::String, ::PyCall.PyJlError)` (1/2 union split): e = PyCall.pyerror(PyCall.string((e::Union{PyCall.PyError, PyCall.PyJlError}).msg::String, "\n\n", msg::String, "\n")::String, e::Union{PyCall.PyError, PyCall.PyJlError})
└─────────────────────────────────────────────────────

https://github.com/aviatesk/JET.jl/issues/450

[stevengj]

The object e is created by e = pyerror("PyImport_ImportModule"). I think JET is upset by the fact that pyerror is currently type-unstable: it may return either an instance of PyError or PyJlError, but the latter only occurs in pyjlwrap callbacks. In pyimport it should always be a PyError, in which case it has a msg field and this is safe.

So, I don't think this is a bug in PyCall. But probably the code could be cleaned up so that in pyimport we call a version of pyerror that is guaranteed to return a PyError object.