fix ice where unsafe fn was incorrectly handled

[Kivooeo]

r? WaffleLapkin (it seems that the fixme in wildcard branch is yours, and i partially resolved it, at least as far as i understand, you might have different vision and/or feel free to reroll in case you are busy with irl things)

i don't quite fully understand this part of code, but it somewhat working, at least i don't fully understand the part why cases like

    let x: fn() = if true {
        (|| ()) as fn()
    } else {
        (|| ()) as unsafe fn()
    };

    let x: unsafe fn() = || ();
    let y: fn() = x as fn();

is already correctly rejected by compiler, but this snippet from issue with match isn't

second unsureness is from i dont really understand if this is correct to emit error like this

so the problem is that this gets into wildcard where it get replace with *entry.get_mut() = adj; (also after this gets replaced it breaks mir) and just hoping for best, but then this closure gets into fn_sig() and ices (at least this is from my perspective, im not really familiar with this part of code)

according to what i said above, the best approach i came up with is add the special case for this and emit error

in case i do span_delayed_bug instead of hard error i still get this

error: internal compiler error: broken MIR in DefId(0:3 ~ main[de72]::fndef) (_1 = move _4 as fn() (PointerCoercion(ClosureFnPointer(Safe), Implicit))): bad assignment (Binder { value: unsafe fn(), bound_vars: [] } = Binder { value: fn(), bound_vars: [] }): NoSolution

also not sure about error message itself if everything else is fine, maybe just using "match arms have incompatible types"

fixes #150128

[rustbot]

WaffleLapkin is currently at their maximum review capacity.
They may take a while to respond.

[BoxyUwU]

very strongly related to #148320

[WaffleLapkin]

Note: this is not my fixme, it got introduced by ariel in 03b0d99#diff-b65997b61ccd8d8e08238c925d631207671aca506e93ce7c5cfa0bec134c0a8eR1679-R1680 (#41279) and I merely moved it (after it got moved a bunch of other times).

[WaffleLapkin]

r? @jackh726

[jackh726]

Just as a heads up: I'm currently doing some very in-depth investigation and experimentation on coercions in the compiler (because of concerning & inconsistent behavior I found) and am very hesitant to merge any changes to coercion at the moment.

This particular PR is small and I will get back to it, but given it just accepts more code to compile, I'm not keen to rush back to it.

[rust-bors]

☔ The latest upstream changes (presumably #151911) made this pull request unmergeable. Please resolve the merge conflicts.