RFC hide func args in backtrace by default

[KristofferC]

Function definition arguments in the backtrace often leads to large backtraces that might fill the whole REPL window.

This commit makes them hidden by default but adds a check for an enviromental variable "JULIA_ARGS_BACKTRACE" and shows them in case that is found.

It also adds an unexported function Base.REPL.show_lasterror() that reshows the last error the REPL showed.

An example with the following code:

    type ThisisALongTypeThatWeMightNotWantToSee end
    typealias TL ThisisALongTypeThatWeMightNotWantToSee

    @noinline ff(x) = (a = rand(5); a[6])
    @noinline function g(a::TL, b::TL, c, d::Float64, e::Float64, f::TL, n)
        if n == 0
            return ff(2)
        else
            g(a, b, c, d, e, f, n-1)
        end
        return 0
    end

    @noinline h(x) = g(TL(), TL(), 2, 1.0, 2.0, TL(), 4)


    function test_it(args...)
        h(2.0)
    end

   test_it()

Ref #18068

Would be interesting to hear your opinions. If you think it is a crap change, say so :) I can take it.

[yuyichao]

I'm ok with this if we can agree to close any issue report immediately without the option on.

[yuyichao]

In another word, I think we can have this option but is default to the current behavior. Error and backtraces are expected to happen very infrequently (and possibly not very reproducible) so putting more information in it should be the default.

In situations that this is not the case (e.g. if you are writing a new package) and if you think you are good enough at guessing the problem you can turn on the option to hide those info in your development sessions/in your .juliarc. (edit: i.e. this is a developer option which is why it should be off by default)

Bug report should always contain the maximum amount of information we can possibly collect.

[KristofferC]

Error and backtraces are expected to happen very infrequently

I don't know. For interactive use they are quite common. The vast majority of the errors being thrown are for people experimenting with their own code. At least for me my thought process is almost always "Oh, BoundsError / MethodError, where did it happen?" and the current level of printing makes answering that question difficult.

Your point about worse default information for bug reports is very valid though.

[yuyichao]

For interactive use they are quite common. The vast majority of the errors being thrown are for people experimenting with their own code.

That's exactly because you are developing your code. If you spend enough time looking at these additional information to think they are annoy, it should be very easy to turn it off with a simple setting in .juliarc.jl.

For users of packages that only care about the error itself (assuming most user facing error contains enough information to fix the input), I think the right way to improve user experience there is to print the error after the backtrace (or maybe print the type of the error first, and the more verbose form last like what ipython does) so that ppl who care only about errors rather than backtraces can more easily find the information they want.

[yuyichao]

Of course printing the error after the backtrace can cause issue if printing the backtrace crashes, which is why printing the type of the error first might be useful. FWIW though, printing the backtrace should be more reliable (it's an object of known type at least) and less likely to crash than printing an error of arbitrary type/referencing arbitrary objects.

[tkelman]

Would also rather make this opt out instead of opt in. We need a better overall verbosity / logging control mechanism at some point.

[KristofferC]

Hitting the limit of my artistic capabilities here.. Opinions @yuyichao?

Reversed the backtrace, detailed error on bottom, some line breaking and colors etc. Too much fruit salad?

[yuyichao]

Color difference looks great, empty lines may or may not be necessary with color output.

Not sure if I like the revered backtrace order though. (Mainly because it's the opposite with the gdb order and the one printed on crashes by us and glibc)

[yuyichao]

OTOH, the reversed backtrace does put the most relevant info closes to the the end so maybe that's something one can easily get used to....

[KristofferC]

FWIW IPython has it in this order and it makes sense to me to have the full error message close to the frame it got thrown.

[Sacha0]

The additional structure and color in #18215 (comment) make visually parsing that backtrace much easier for these eyes. +1 for something like this!