Pre-RFC: allow reuse default stacktrace display style for `std::backtrace::Backtrace`

[target_san]

Hello

I noticed some inconveniences in current panic handling and backtrace collection

1. std::panic::catch_unwind doesn't introduce additional marker stack frame, __rustc_begin_short_stacktrace, which results in longer stacktrace tails. Any opinions on inserting one and wrap invocation of closure passed to catch_unwind?
2. std::backtrace::Backtrace is displayable yet uses completely different printing from builtin backtraces and respects neither BacktraceStyle nor RUST_BACKTRACE. Possible tweaks:
   • Add std::panic::BacktraceStyle::from_env() -> Self which would create style from RUST_BACKTRACE environment variable
   • Add std::backtrace::Backtrace::display(&Self, BacktraceStyle) -> BacktraceDisplay<'_> which creates display object for backtrace which in turn prints it according to specified style, using default backtrace print code. This includes respecting short backtrace markers.
3. Would it be preferable to first write MVP implementation? Or discuss it as RFC?

Thanks

[bjorn3]

@target_san

std::backtrace::Backtrace is displayable yet uses completely different printing from builtin backtraces and respects neither BacktraceStyle nor RUST_BACKTRACE.

Backtrace::capture() should return an empty backtrace when neither RUST_BACKTRACE not RUST_LIB_BACKTRACE are set.

@target_san

std::panic::catch_unwind doesn't introduce additional marker stack frame, __rustc_begin_short_stacktrace, which results in longer stacktrace tails. Any opinions on inserting one and wrap invocation of closure passed to catch_unwind?

I personally don't think this should be done. catch_unwind was originally introduced to turn panics into error return values at FFI boundaries. You almost certainly do want the backtraces to pass through the FFI boundary. __rustc_begin_short_stacktrace and __rustc_end_short_stacktrace are specifically for stack frames that are implementation details of libstd and as such almost never useful for anyone not working on libstd.

[target_san]

@bjorn3

@target_san

std::backtrace::Backtrace is displayable yet uses completely different printing from builtin backtraces and respects neither BacktraceStyle nor RUST_BACKTRACE.

Backtrace::capture() should return an empty backtrace when neither RUST_BACKTRACE not RUST_LIB_BACKTRACE are set.

Yes, but I'm talking about short vs full backtraces, the way default panic handler prints them. There's experimental std::panic::BacktraceStyle but it can influence only global state ATM. Backtrace is always printed in full, except few frames above Backtrace::capture

@bjorn3

@target_san

std::panic::catch_unwind doesn't introduce additional marker stack frame, __rustc_begin_short_stacktrace, which results in longer stacktrace tails. Any opinions on inserting one and wrap invocation of closure passed to catch_unwind?

I personally don't think this should be done. catch_unwind was originally introduced to turn panics into error return values at FFI boundaries. You almost certainly do want the backtraces to pass through the FFI boundary. __rustc_begin_short_stacktrace and __rustc_end_short_stacktrace are specifically for stack frames that are implementation details of libstd and as such almost never useful for anyone not working on libstd.

Yes, but catch_unwind may be used in scenarios like testing. I encountered extremely long backtraces when working with proptest. My idea is to make short backtrace between panic frame itself and topmost catch_unwind. Please note these marker frames influence only how backtrace is displayed in short mode, not how it's collected.

[carbotaniuman]

@target_san

Please note these marker frames influence only how backtrace is displayed in short mode, not how it's collected.

I think it would be very annoying to have to debug a stack trace where arbitrary libraries can hide backtrace frames, obscuring the root of the problem.