Support hiding specific stackframes from backtrace by marking on the original functions.

[crlf0710]

Recently #[track_caller] usages has landed on nightly channel, which is really great! However i want to request a little more here. Currently

fn main() {
    panic!("foo");
}

output is:

thread 'main' panicked at 'foo', src/main.rs:2:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:77
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1057
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1426
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:472
  11: std::panicking::begin_panic
             at /rustc/689fca01c5a1eac2d240bf08aa728171a28f2285/src/libstd/panicking.rs:399
  12: playground::main
             at src/main.rs:2
  13: std::rt::lang_start::{{closure}}
             at /rustc/689fca01c5a1eac2d240bf08aa728171a28f2285/src/libstd/rt.rs:67
  14: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  15: std::panicking::try::do_call
             at src/libstd/panicking.rs:305
  16: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:86
  17: std::panicking::try
             at src/libstd/panicking.rs:281
  18: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  19: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  20: std::rt::lang_start
             at /rustc/689fca01c5a1eac2d240bf08aa728171a28f2285/src/libstd/rt.rs:67
  21: main
  22: __libc_start_main

However, of the 22 stack frames, only 3 or 4 is meaningful to user. It would be great if rest of the functions can be marked with a special attribute, and maybe marked somehow in the mangled symbol, then be excluded from the default display of backtrace.

[crlf0710]

@rustbot modify labels to +A-runtime +C-feature-request +T-lang

[ehuss]

I would say this is a duplicate of #58554. There is a long history of filtering irrelevant frames, see #38165 (implemented filtering), #25621, #60852 removed the (broken) filtering when switching to the backtrace crate.

[crlf0710]

@ehuss #58554 talks about removing some frames at the start and end of the backtrace. That's quite limited and error-prone to me. In the above example, i think it will be great if we filter out 0-3, 6, 8-10, 13-17, 19, 21-22. I agree that's #58554 is talking about solving exactly the same problem, but i don't really like that approach that issue is suggesting.

[eddyb]

@crlf0710 I don't understand why you would want to see anything above 12, it's all predictable panic machinery (which happens to be on the stack when the backtrace is produced, and I believe that's what #58554 is focusing on).

There's also not much interesting below 12, either, in that case it's predictable (maybe std could track the stack pointer just before calling main, and take that into account when obtaining backtraces?)

[crlf0710]

@eddyb I'm not insisting on seeing any specific frame. In the above very simple example, i think it's very fine to omit most of the frames.

Actually what i'm trying to say is that, we want to filter these out not because they're at the start and end of the frame, but they're actually implementation details of the rust runtime. Other people, when writing rust framework or runtime system, will likely want to hide their implementation details, too. People will not only want to hide implementation detail of "main" and "panic"(which correspond to the start of stack and end of stack), but also async runtime executors, iterator combinator forwardings, trait object shim functions, drop functions and so on. I am seeking for something more extensible than #58554 here, but it doesn't have to rush to be opened to surface users.