Better line info for "missing comma or ) in argument list" error

[KristofferC]

Putting this in a file and include it:

function filler()
end

function g(a,b,c)
    f(a,b)
    f(a,b)
    f(a,(b,))
    f(a,(b,))
    f(a,(b,))
    f(a,(b,) # :(
    f(a,(b,))
    f(a,(b,))
    f(a,(b,))
end

gives the error message:

julia> include("test.jl")
ERROR: LoadError: syntax: missing comma or ) in argument list
 in include(::ASCIIString) at ./boot.jl:233
 in include_from_node1(::ASCIIString) at ./loading.jl:426
 in eval(::Module, ::Any) at ./boot.jl:236
while loading /home/kristoffer/Documents/test.jl, in expression starting on line 4

Is there anyway the line info could be a bit more specific than just the line of the start of the enclosing function?

[yuyichao]

Dup of #15643

[KristofferC]

That one has the title "bad stack trace for errors in macros". This example has no macros. Should the title in #15643 be updated?

[JeffBezanson]

Looks like a different issue to me. This one is about syntax error locations.

[Keno]

Or you could just use JuliaParser ;):

[KristofferC]

Wow, that is some clang level beauty right there.

[Keno]

The README has instructions: https://github.com/JuliaLang/JuliaParser.jl#using-juliaparser-as-your-primary-parser

[KristofferC]

Here is another example from a typo I made:

# test.jl
module Test

function filler()
    blabla
end

typealias a = Float64

end # module

julia> include("/home/kristoffer/Documents/test.jl")
ERROR: LoadError: syntax: unexpected "="
 in include_from_node1(::String) at ./loading.jl:426
 in eval(::Module, ::Any) at ./boot.jl:230
while loading /home/kristoffer/Documents/test.jl, in expression starting on line 1

[KristofferC]

Another one:

module M

function f()
    while true
        if x == 0 && y == 0
            a = 1
        if x == 1 && z == 1
            a = 2
        end
    end
end

end

This gives ERROR: syntax: incomplete: "module" at REPL[44]:1 requires end. For a large modules this is a quite unhelpful error and I usually end up pasting the whole module in the REPL and see where the latest completely parsed expression got completed. Maybe the Error message could show this as well?

[StefanKarpinski]

I think the best way to give better error messages is probably to consider indentation. To me that suggests bailing out on a parse when there's an error and reparsing the input with a parser that is slower and tracks extra information like indentation and gives really high quality messages.