False non-primitive cast diagnostic

[Veykril]

fn f() {
    trait T {
        fn f() {}
    }
    impl T for i32 {}
    impl T for u32 {}
    &[i32::f, u32::f] as &[fn()];
}

triggers two false diagnostics

non-primitive cast: `&[fn f<i32>(); 2]` as `&[fn()]`rust-analyzer[E0605](https://doc.rust-lang.org/stable/error_codes/E0605.html)
expected fn f<i32>(), found fn f<u32>()rust-analyzer[E0308](https://doc.rust-lang.org/stable/error_codes/E0308.html)

[ChayimFriedman2]

This appears to be a problem in Chalk, it assumes two different FnDefs (or Closures) cannot unify, while rustc coerces them to fn() if possible.

@Veykril Should we fix this now or wait for the new trait solver?

[Veykril]

Probably fine to wait, I noticed this because I introduced it in the r-a codebase now. But if no one else reports it its probably not high impact. Is it right that this is the on the trait solver here though and not us failing to do a correct coercion?

[Veykril]

Also this can be worked around by coercing the first element of the array to the function pointer via another cast (&[i32::f as fn(), u32::f] as ....

[ChayimFriedman2]

Oh wait! No, this isn't a problem in Chalk, my mistake. I will fix this soon.