Open dev-ardi opened 3 months ago
The first two bullets would be a good start:
Red for the actual error gray for the panicking code (0-2) This is mostly noise so it makes sense to treat it differently
The last 3 do not have a clear implementable definition:
green for library code blue for dependencies white for user code. It must stand out
Couldn't we try some heuristics for the last three?
crates.io
it's a dependencyrustc
it's library codeA backtrace in the default release profile looks like this:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: scratch::main
So that heuristic is implementable, but it falls apart in a default configuration which seems bad.
Well yes, it will fail for release builds without debug symbols. We could suggest to enable symbols for a better backtrace. It would also be very helpful for tools with many, many stack trace messages like AddressSanitizer and ThreadSanitizer.
If we figure out better heuristics at some point we can improve the coloring then. Having a fallback to "not color anything" is no worse that what we have right now.
White is probably not the greatest for user code then, that should be reserved for unknown.
It would also be very helpful for tools with many, many stack trace messages like AddressSanitizer and ThreadSanitizer.
No, it wouldn't. Those tools do their own backtrace printing that we do not maintain.
People use white-background terminals. Using a foreground white is right out.
Making the text bold/increased intensity (CSI 1 m
) rather change the text color to bright white (CSI 97 m
) should work fine when using a white background.
Yes, that sounds fine.
I mean, I'll still have to judge it by how it actually looks, but it sounds fine as-such.
Red for the actual error
I don't understand what actual error means. I'm think of it to be the first BacktraceFrame but I don't know if I'm getting it wrong. Can you be more detailed?
Is it possible that we have better stack traces?
There is so much information on them, yet they are difficult to parse. This could be improved somewhat via coloring!:
See a typical backtrace, it's hard to find where the error happened:
Some example colors
Also for the
at /home/ardi/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/blocking/task.rs:42:21
It's good to have the full path so I can jump into it and see what failed, but it's a good idea to highlight the important information: at /home/ardi/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/runtime/blocking/task.rs:42:21