Calling unwind via function pointer leads to odd panic message

[RalfJung]

I was playing around with function pointers to track_caller methods (which doesn't seem entirely implemented yet) and arrived at the following testcase:

fn call_it<T>(f: fn(T), x: T) {
    f(x);
}

fn main() {
    call_it(Result::unwrap, Err(0));
}

On stable, this behaves as expected:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: 0', src/libcore/result.rs:1165:5

On the latest nightly though, the message is different:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libstd/panicking.rs:369:15

The line number points at this:

rust/src/libstd/panicking.rs

Line 369 in af95804

let loc = info.location().unwrap(); // The current implementation always returns Some

Two things seem odd here for me:

• I am actually surprised that this does not ICE, given that the ReifyShim stuff does not seem entirely implemented (at least this test still ICEs).
• But the actual main bug here is that the comment about "always returns Some" seems wrong, so this panics at the wrong place. Clearly, the message shouldn't talk about Option::unwrap() when the actual panic is caused by a Result::unwrap.

Cc @anp

[eddyb]

(ignore previous comment if you saw it, play.rust-lang.org's nightly is from the the wrong decade...)

[anp]

Here's a repro of the underlying issue. We're missing logic in https://github.com/rust-lang/rust/blob/master/src/librustc/ty/instance.rs#L143-L145 to:

16:29 <eddyb> anp: it should be matching on `InstanceDef::Item(def_id)`, not use `.def_id()`
16:29 <eddyb> that is, `Item` is the only one where it's safe to return `true`

cc @eddyb

[anp]

Working on fleshing out this failing test case to include const fn's and will open a PR to resolve it.

[anp]

As for why the confusing error message: a PanicInfo is being created with self.location set to a null static reference, Some(null) is None, and we get an unwrap failing where it shouldn't.

[anp]

Started #68302, just failing tests for now.

[anp]

Have fixes for both bugs running through CI now.