change handling of subtyping to be less fragile after analysis

edit: no longer up-to date. the current plan is to add the explicitly add the source type to MIR casts instead

We should add a MIR pass after analysis (and before any optimizations) which makes subtyping explicit in the MIR. This is a robust way to fix #107205, preventing similar issues in the future. I don't quite know how to do that, probably by adding an explicit ProjectionElem::Cast (probably reusing OpaqueCast for that).

When implementing this, also handle all the FIXME(#112651) added in #112307

@rustbot

@rustbot claim

Auto merge of rust-lang#115025 - ouz-a:ouz_testing, r=lcnr

Auto merge of #115025 - ouz-a:ouz_testing, r=lcnr

Should this be closed now that #115025 has been merged?

edit: I guess there are still some FIXMEs referencing this issue

we encountered an issue with function pointers:

fn main() {
    let x: fn(fn(&'static ())) = some_function;
    let y: fn(for<'a> fn(&'a ())) = x;
    y(|&()| ());
}

here we can make subtyping inside of main explicit, resulting in something like the following

fn main() {
    let x: fn(fn(&'static ())) = some_function;
    let y: fn(for<'a> fn(&'a ())) = x as fn(fn(&'static ()));
    y(|&()| ());
}

however, when calling y, it is still a function pointer to some function expecting fn(&'static ()). This means that the calling y results in implicit subtyping. To handle this the let y = x assignment would also have to wrap the value of x to explicitly subtype. Modifying values in this way feels very difficult implement. Especially given that the function pointer could be nested in x, e.g. in some union or whatever.

As this means that subtyping has to still be implicitly handled somewhere, I believe that it's safer to always implicitly handle this. I believe that it's otherwise easier to accidentally rely on subtyping being explicit, resulting in bugs which are even harder to diagnose.