errors inside macros give incorrect line numbers

[jump-dev]

errors inside macros give incorrect line numbers

[IainNZ]

The 'true' issue is JuliaLang/julia#1334, still open

[mlubin]

Unfortunately not fixed after JuliaLang/julia#12544:
After a slight syntax update, dummy.jl becomes

using JuMP
m = Model()
@setObjective(m, Max, z)

and I get

ERROR: LoadError: UndefVarError: z not defined
 in include at ./boot.jl:260
 in include_from_node1 at ./loading.jl:271
 in process_options at ./client.jl:308
 in _start at ./client.jl:411
while loading /home/mlubin/dummy.jl, in expression starting on line 584

[leotac]

Ouch, no luck on this yet? It's rather annoying :(

[mlubin]

We may have to restructure the macros to take advantage of the recent improvements, but I haven't looked into it.

[mlubin]

@ihnorton, I didn't follow all of the nuances of JuliaLang/julia#12544, but what do we have to do in JuMP to get call site line numbers reported correctly?

[ihnorton]

You want it to report UndefVarError on line 3, correct?
Can I just do Pkg.add("JuMP") and run your example?

To clarify, 12544 is about getting correct line numbers when generated code throws an error. If I am understanding the situation here, the error is being thrown during macro expansion, so none of the generated code is actually running yet. See the second part of my comment here about errors during macro expansion (can't throw across the flisp stack). This PR is relevant, although I think I might be able to get you UndefVarError on line 3 without it (or with a much less intrusive version -- only annotate on the flisp side).

[mlubin]

Yes, the example should run with vanilla JuMP.
On Oct 2, 2015 5:52 PM, "Isaiah" [email protected] wrote:

You want it to report UndefVarError on line 3, correct?
Can I just do Pkg.add("JuMP") and run your example?

To clarify, 12544 is about getting correct line numbers when generated
code throws an error. If I am understanding the situation here, the
error is being thrown during macro expansion, so none of the generated code
is actually running yet. See the second part of my comment here
JuliaLang/julia#8701 (comment)
about errors during macro expansion (can't throw across the flisp stack). This
PR JuliaLang/julia#13339 is relevant, although
I think I might be able to get you UndefVarError on line 3 without it (or
with a much less intrusive version -- only annotate on the flisp side).

—
Reply to this email directly or view it on GitHub
#7 (comment).

[mlubin]

@ihnorton, the error is at run time, not macro expansion.

[ihnorton]

Thanks. With the simplified example, 12544 doesn't apply because the error is being thrown by the interpreter. JuliaLang/julia#13444 should help there.

I assume you also want to use these macros inside of functions, where 12544 would apply, however, the location will still be off because I haven't figured out how to track the top-level location properly with nested locations, so right now we just default to the starting line number of the function body.

[mlubin]

I definitely get a better backtrace when I put the code into a function:

using JuMP
function foo()
    m = Model()
    @setObjective(m, Max, z)
end
foo()

gives

ERROR: LoadError: UndefVarError: z not defined
 [inlined code] from /home/mlubin/.julia/v0.4/JuMP/src/macros.jl:602
 in foo at /home/mlubin/dummy.jl:601
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:304
 in process_options at ./client.jl:308
 in _start at ./client.jl:411
while loading /home/mlubin/dummy.jl, in expression starting on line 7

Though it's pointing to line 601 from dummy.jl which doesn't exist, it's macros.jl:601.

[ihnorton]

With JuliaLang/julia#13431 that should show as dummy.jl:3. Clearly that's still off by one -- it's the function start rather than the actual line, as per my comment above -- but at least on a line that actually exists!

[mlubin]

@ihnorton, on master I'm now getting:

ERROR: LoadError: LoadError: UndefVarError: z not defined
 [inlined code] from /home/mlubin/.julia/v0.5/JuMP/src/macros.jl:584
 in foo at /home/mlubin/dummy.jl:4
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:384
 [inlined code] from ./operators.jl:313
 in process_options at ./client.jl:277
 in _start at ./client.jl:377
while loading /home/mlubin/dummy.jl, in expression starting on line 6
while loading /home/mlubin/dummy.jl, in expression starting on line -1

[mlubin]

This seems to basically be fixed now? If we find another instance of bad backtraces we can open a new issue.