Add support for RUST_LIB_BACKTRACE variable

[yaahc]

Loosely based on this part of std

https://doc.rust-lang.org/stable/src/std/backtrace.rs.html#228-247

closes #30

[athre0z]

If I understand the distinction between RUST_BACKTRACE and RUST_LIB_BACKTRACE correctly, the former is used when capturing panic traces using the default panic handler and the latter is employed when a user manually captures backtraces, e.g. as context for their own errors. Is that correct? Until you created this issue I didn't even realize the latter existed, so I want to make sure I understand it correctly.

If my assumptions above are correct, shouldn't we somehow mirror this by having two distinct verbosity levels -- one for when used as a panic handler and one for printing user provided backtraces?

[yaahc]

Yes we should, I'll fix that

[yaahc]

Hmm, it seems like there are a few options here for how to move forward but I'm not really sure which one you'd prefer.

The main issue is the BacktracePrinter has a single verbosity level and is shared between the panic hook printing and the direct backtrace printing. Here are the solutions I can think of:

• carry around two verbosity levels, track if the printing logic is being invoked via print_panic_info and use the correct level
• split the printer so that we have one for panic printing and one for backtrace printing (breaking change i assume)

Additionally, I didn't notice before but you already added the ability to override the verbosity, so technically this issue isn't really required, I can get the correct verbosity level set in my crate even without merging this, so I guess the 3rd option is just to close this, though I do think it would be idea to provide some level of RUST_LIB_BACKTRACE support in the defaults.

[athre0z]

I'd say we go with the first option.

We'll also need a second from_env func -- perhaps call it lib_from_env or something like this. Totally non-intuitive name, but I can't come up with anything better right now. Same goes for the prefix for the second verbosity level. Better suggestions more than welcome.

[yaahc]

We'll also need a second from_env func -- perhaps call it lib_from_env or something like this. Totally non-intuitive name, but I can't come up with anything better right now. Same goes for the prefix for the second verbosity level. Better suggestions more than welcome.

I'm gonna pass on bikeshedding internal API names, lib_from_env sounds great to me, lol

[athre0z]

Hahaha, alright, lib_from_env it is. :D

[yaahc]

Should these methods follow std's example and make some effort to cache these values?

[athre0z]

Nah, I think this is fine as-is. I'd argue that panic printers and thus verbosity instances are generally constructed only few times per app-run and it wouldn't be worth the effort.

[athre0z]

Thanks, excellent PR!

[athre0z]

Nah, I think this is fine as-is. I'd argue that panic printers and thus verbosity instances are generally constructed only few times per app-run and it wouldn't be worth the effort.