wrong backtrace line for .unwrap() if it is on the next line

[matthiaskrgr]

meta:

rustc 1.37.0-nightly (5eeb567a2 2019-06-06)
binary: rustc
commit-hash: 5eeb567a27eba18420a620ca7d0c007e29d8bc0c
commit-date: 2019-06-06
host: x86_64-unknown-linux-gnu
release: 1.37.0-nightly
LLVM version: 8.0

I had a Command::new()....unwrap() and some methods in between that were also unwrapping their arguments. The panic that I got however was not pointing to any of the unwrap()s but to the first line of the statement (the Command::new()) which is quite confusing.

Here is similar example:

 fn a(_: i32, _: i16, _: i8, _: i32, _: i16, _: i8) -> i32 {
    4
}

fn main() {
    let X: i32 = a(
        9,
        Some(4)
        .unwrap(),
        Some(7)
        .unwrap(),
        Some(9)
        .unwrap(),
        Some( // backtrace points here
        None
        )
        .unwrap()
        .unwrap(), // should point here
        7,
    );
}

the backtrace points to line 15 which contains Some( which is very confusing, imo it should point to line 19 which is the panicking unwrap()

Can reproduce on stable, beta and nightly. Playground: https://play.rust-lang.org/?version=beta&mode=debug&edition=2018&gist=be591b1d4dbf5b729c5733a831c823e9

[Centril]

From a strict interpretation of the language's rules I think the current behavior is correct as the syntactical unit is receiver_expr "." method_name "(" args ")". However, I can see how pointing towards the .method_name( bit might be more useful.

[czipperz]

I believe this originates in the backtrace crate. At least that's where the error message is gotten from. It may be that for ease of debugging, this style is chosen.

[czipperz]

That is when using a graphical debugger, we want to look at the Some( line as it is the beginning of the expression so that is why it is encoded that way.

[sfackler]

The backtrace crate just reads out the debuginfo that the compiler places in the binary. That's what needs to change.

[pnkfelix]

Visiting for wg-debugging triage

We just wanted to check whether the described problem still persists.

The given playground currently prints:

warning: `playground` (bin "playground") generated 2 warnings
    Finished dev [unoptimized + debuginfo] target(s) in 1.36s
     Running `target/debug/playground`
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/main.rs:18:10
stack backtrace:
   0: rust_begin_unwind
             at /rustc/da7ffa2d1df2daf747b8e4bdf5659c942abb22af/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/da7ffa2d1df2daf747b8e4bdf5659c942abb22af/library/core/src/panicking.rs:142:14
   2: core::panicking::panic
             at /rustc/da7ffa2d1df2daf747b8e4bdf5659c942abb22af/library/core/src/panicking.rs:48:5
   3: core::option::Option<T>::unwrap
             at /rustc/da7ffa2d1df2daf747b8e4bdf5659c942abb22af/library/core/src/option.rs:775:21
   4: playground::main
             at ./src/main.rs:14:9 <------- this is what the issue is complaining about
   5: core::ops::function::FnOnce::call_once
             at /rustc/da7ffa2d1df2daf747b8e4bdf5659c942abb22af/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Our understanding, like that of other comments in the thread, is that the debuginfo starts with the span of the receiver expression, which is why you see this pointing to the Some( at the start, rather than the specific unwrap that failed.

But it might be interesting to figure out if the DWARF debuginfo could carry both the receiver expression span and the method call span.

(I would be hesitant to just change everything to always point to the method call span. That could cause a lot of disruption to existing workflows for people.)