Unexpectedly long method signature in "Closest candidates" list

Sukera · December 21, 2019, 11:04am

Stacktrace gripes

opened 06:31PM - 24 Aug 19 UTC

error handling display and printing

Stacktraces are in general pretty hard to read. Here's a list of gripes. I'm not… posting this as separate issues because I don't know what is bug and what is feature here. All tests are on 1.3alpha from an official release. This is related but not the same as https://github.com/JuliaLang/julia/issues/25375, which is about formatting. Let's start small: ``` julia> sqrt(-2) ERROR: DomainError with -2.0: sqrt will only return a complex result if called with a complex argument. Try sqrt(Complex(x)). Stacktrace: [1] throw_complex_domainerror(::Symbol, ::Float64) at ./math.jl:32 [2] sqrt at ./math.jl:492 [inlined] [3] sqrt(::Int64) at ./math.jl:518 [4] top-level scope at REPL[4]:1 ``` * Where is `./math.jl`? * I don't care that [2] is inlined * The last frame is unnecessary (the :1 definitely is, and I don't know what the [4] is) Now a stdlib: ``` julia> lu([0 0;0 0]) ERROR: SingularException(1) Stacktrace: [1] checknonsingular at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/LinearAlgebra/src/factorization.jl:19 [inlined] [2] #lu!#128(::Bool, ::typeof(lu!), ::Array{Float64,2}, ::Val{true}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/LinearAlgebra/src/lu.jl:85 [3] #lu! at ./none:0 [inlined] [4] #lu#134(::Bool, ::typeof(lu), ::Array{Int64,2}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/LinearAlgebra/src/lu.jl:295 [5] lu(::Array{Int64,2}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/LinearAlgebra/src/lu.jl:286 [6] top-level scope at REPL[2]:1 ``` * The paths are bad; that means that nice things like ctrl-q will not work, and neither will the functionality in some editors that go to the path. * The keyword arguments lowering, which should really be an implementation detail, is exposed here, and confusing (wtf is [3]?) `include`d user files: ``` julia> include("scratch.jl") ERROR: LoadError: UndefVarError: qsd not defined Stacktrace: [1] f() at /home/antoine/scratch.jl:2 [2] top-level scope at /home/antoine/scratch.jl:4 [3] include at ./boot.jl:328 [inlined] [4] include_relative(::Module, ::String) at ./loading.jl:1094 [5] include(::Module, ::String) at ./Base.jl:31 [6] include(::String) at ./client.jl:432 [7] top-level scope at REPL[3]:1 in expression starting at /home/antoine/scratch.jl:4 ``` * Five frames for the include are hard to read * Having the information at the bottom is confusing: where am I supposed to find the source of the error? In the stacktrace or at the bottom? * The LoadError: UndefVarError is annoying (it gets worse for more complex cases, ie multiple includes) Failing tests: ``` ERROR: LoadError: LoadError: LoadError: DomainError with -2.0: sqrt will only return a complex result if called with a complex argument. Try sqrt(Complex(x)). Stacktrace: [1] throw_complex_domainerror(::Symbol, ::Float64) at ./math.jl:32 [2] sqrt at ./math.jl:492 [inlined] [3] sqrt(::Int64) at ./math.jl:518 [4] @SArray(::LineNumberNode, ::Module, ::Any) at /home/antoine/.julia/packages/StaticArrays/3KEjZ/src/SArray.jl:83 [5] include at ./boot.jl:328 [inlined] [6] include_relative(::Module, ::String) at ./loading.jl:1094 [7] include(::Module, ::String) at ./Base.jl:31 [8] include(::String) at ./client.jl:432 [9] top-level scope at /home/antoine/.julia/packages/StaticArrays/3KEjZ/test/runtests.jl:19 [10] include at ./boot.jl:328 [inlined] [11] include_relative(::Module, ::String) at ./loading.jl:1094 [12] include(::Module, ::String) at ./Base.jl:31 [13] include(::String) at ./client.jl:432 [14] top-level scope at none:5 in expression starting at /home/antoine/.julia/packages/StaticArrays/3KEjZ/test/SArray.jl:30 in expression starting at /home/antoine/.julia/packages/StaticArrays/3KEjZ/test/SArray.jl:1 in expression starting at /home/antoine/.julia/packages/StaticArrays/3KEjZ/test/runtests.jl:19 ERROR: Package StaticArrays errored during testing ``` I'm a bit confused about what's going on here to be honest... I did not try with the other ways of including code, macros, etc. So, to sum up, in subjective increasing order of seriousness * There are minor printing things that could be nicer: REPL frames, LoadError nesting, inline, `./` path for base * The keyword argument lowering is a bit nasty * The paths on official releases should be corrected * The stacktraces with `include` are very hard to parse. This is possibly the most controversial issue because enhancing this would mean "lying" to the user, ie treating `include` as a special function