Reverse the stack traces

[emilk]

A big improvement to the speed at which I can find the origin of a panic would be to reverse the order of the stack trace. At the moment the last line of the stack trace is always main. This means the stack trace is written deep->shallow, or in reverse(!) chronological order:

1:        0x10977219c - function_that_caused_the_panic
2:        0x1097738ee - foo
3:        0x109773590 - bar
4:        0x109773cf6 - baz
5:        0x109773b94 - badger
6:        0x109757669 - main

What you are generally looking for is the place that caused the panic (e.g. the line with an assert! or panic! on it), and so I think it would make sense to have that line last so that it is easy to find. This is particularly important when the call stack is deep and it fills your terminal. Here is a more in-depth argument for this.

So my suggestion is: reverse the stack trace to print the stack frames in chronological order, shallow->deep, with main on the top and the stack frame with the panic at the end:

6:        0x109757669 - main
5:        0x109773b94 - badger
4:        0x109773cf6 - baz
3:        0x109773590 - bar
2:        0x1097738ee - foo
1:        0x10977219c - function_that_caused_the_panic

I realize this can become quite the bikeshedding religious war, and maybe this has been discussed before – if so, I apologize. Still, until the blog post above brought it up I didn't realize that most languages – including Rust – was doing it wrong, and that there was a better way. In C++ I switched the order I print stack traces about a year ago, and since then it has saved me a lot of scrolling.

EDIT: I've created a forum thread about this here: https://users.rust-lang.org/t/reverse-stack-trace-order/8786

[Outpox]

Coming from a JS - PHP background I was used to it because it's more relevant to get the latest error written at the top of the page displaying it.
When I had my first error in Rust I was indeed surprised by this order and expected to see the error on the last line.

[aidanhs]

Perhaps worth a discussion on https://users.rust-lang.org (or internals) instead since I can see it being contentious?

[alexcrichton]

cc #38165 and #37783, other issues for improving the backtrace output

[emilk]

@aidanhs Ok: https://users.rust-lang.org/t/reverse-stack-trace-order/8786

[Yamakaky]

You may want to wait for #38165 to be merged before making your change, as it would be just adding a .rev() at https://github.com/Yamakaky/rust/blob/39f2709dd465d360cc9e3521afd339b49950aceb/src/libstd/sys_common/backtrace.rs#L56.

[emilk]

Note that this suggestion is all about improving the edit-compile-debug cycle, an explicit goal in the 2017 roadmap.

Of course, whether or not it does improve it might be a personal thing. For me it absolutely does. Maybe an option to reverse it is a fair compromise, or at least a start?

[jasonhansel]

I'd like this too! It would also be nice if stack traces had pretty (terminal) colors, perhaps with an extension to RUST_BACKTRACE. Also: it would be useful if one could hide standard library sources from the stack trace.

[steveklabnik]

Triage: no changes here.

[matklad]

Couple of thoughts: at this point, there’s no way we actually flip the default presentation. At the same time, we already allow controlling backtrace formatting via RUST_BACKTRACE env var. I think implementing a nightly-only RUST_BACKTRACE=“short,reversed” would be an immediate win which wouldn’t require too much bike shedding.