Short backtrace sometimes includes unnecessary `core::ops::function::FnOnce::call_once` line

[solson]

Given this file foo.rs:

fn main() {
    panic!();
}

A short backtrace for this panic would ideally include only std::panicking::begin_panic and foo::main. And, indeed, the implementing PR has a test for this output:

rust/src/test/ui/panics/issue-47429-short-backtraces.run.stderr

Lines 1 to 5 in 5792840

	thread 'main' panicked at 'explicit panic', $DIR/issue-47429-short-backtraces.rs:17:5
	stack backtrace:
	0: std::panicking::begin_panic
	1: issue_47429_short_backtraces::main
	note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

However, this is how the backtrace actually looks with various flags:

rustc (no flags; debug mode)

   0: std::panicking::begin_panic
   1: foo::main
   2: core::ops::function::FnOnce::call_once

rustc -O (release mode)

   0: std::panicking::begin_panic
   1: foo::main

rustc -O -C debuginfo=1 (release mode with debuginfo)

   0: std::panicking::begin_panic
             at ./.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:505
   1: foo::main
             at ./foo.rs:2
   2: core::ops::function::FnOnce::call_once
             at ./.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227

So I think the __rust_begin_short_backtrace implementation needs to account for this extra stack frame when it isn't optimized out by release mode. The test mentioned above only passes because it's compiled with -O:

rust/src/test/ui/panics/issue-47429-short-backtraces.rs

Line 3 in 5792840

// compile-flags: -O

I tested this on 1.47.0 stable and a nightly version:

rustc --version --verbose

rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-unknown-linux-gnu
release: 1.47.0
LLVM version: 11.0

rustc 1.49.0-nightly (91a79fb29 2020-10-07)
binary: rustc
commit-hash: 91a79fb29ac78d057d04dbe86be13d5dcc64309a
commit-date: 2020-10-07
host: x86_64-unknown-linux-gnu
release: 1.49.0-nightly
LLVM version: 11.0

ref #75048
cc @eggyal

[eggyal]

We were aware that the invoking closure is inlined on some platforms but not on others — see #75048 (comment) and subsequent comments. Not sure that there's much value in overriding optimisations to force consistency on this minor point? Cc @michaelwoerister

[solson]

I reported this since it was a bit confusing that the Rust announcement post itself included the irrelevant (to the end user) call_once line. It seems unfortunate to me that debug mode has the more confusing backtrace in this case — I probably use backtraces most often during development, without optimizations.

[eddyb]

This would go away if lang_start would be generic over main's type as F: FnOnce() -> R instead of taking a fn pointer, right? If you use -Z symbol-mangling-version=v0, you can see that the "inlined sometimes" call_once is <fn() as core::ops::function::FnOnce<()>>::call_once, i.e. the shim for calling a fn pointer via FnOnce.

One nice thing would that is we could theoretically allow varying not just main's return type, but also argument counts/types (which frankly I don't know why it hasn't come up before?).