Trait objects missing `#[track_caller]` shims

[anp]

After reducing a repro of a potential track_caller bug from @yaahc, I get a segfault from this code:

trait Handler {
    fn handle(&self);
}

impl<T> Handler for T {
    #[track_caller]
    fn handle(&self) {
        assert_eq!(std::panic::Location::caller().file(), file!());
    }
}

fn main() {
    let handler: &(dyn Handler) = &5u8;
    handler.handle();
}

This repros for me on my up-to-date checkout as well as for the current beta compiler. I'm not sure whether that makes this a regression from stable to beta, since it's an apparent bug in an API which is first stabilizing in this release.

cc @eddyb

[lcnr]

this causes a segfault on stable:

use std::ops::Index;

fn main() {
    let vec = vec![1];
    let handler: &dyn Index<usize, Output = i32> = &vec;
    handler.index(2);
}

results in

thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 2', Segmentation fault (core dumped)

Luckily dyn Index is very rarely used

[anp]

Oof! I'm looking at the existing tests and I realize what we missed. We test direct calls to tracked trait methods and we test indirect calls to tracked trait functions (i.e. no receivers), but we don't test indirect calls of trait methods with receivers.

[anp]

My immediate suspicion is that trait object vtables aren't going through the reification path we added to Instance::resolve_for_fn_ptr.

[anp]

Thanks to @eddyb for confirming this doesn't seem to affect self-by-val.

[anp]

Opened #74784 with a fix, thanks again to @eddyb for help finding the missing call!