Suggest considering casting fn item as fn pointer in more cases

[mu001999]

Fixes #132648

[rustbot]

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[compiler-errors]

Thanks for the contribution, but I think this logic is a bit too ad-hoc to land.

As an alternative approach, could you find the logic that ends up producing this note:

for that trait implementation, expected fn() found fn() {foo}

And instead try to add a note there? That logic should be responsible for peeling off all the types until the type mismatch, which should make it much simpler and not require us to reimplement a new kind of method to peel off ADTs to discover fn type mismatches.

[mu001999]

@compiler-errors Just checking the found ty and expected ty at fulfillment_errors.rs will work, but it only handles the cases that we know both tys are fns.

I want to suggest in more cases, just like the second statement in the test, e.g., let _: Vec<fn()> = Vec::from([foo]);. We got expected Vec<fn()>, and found Vec<fn() {foo}>, so I add the logic to help do this.

Do you think just adding a help for the simple case is enough? If so I can open another PR which will do less ;)

[compiler-errors]

@mu001999: What I'm saying is that this logic largely replicates, and I don't think I can see why this needs to be reimplemented in a particularly verbose way.

When we have a type mismatch like Vec<fn()> and Vec<fn() {foo}>, we return something called TypeError::Sorts that should contain the fn pointers themselves.

I think that working backwards to understand the function and trying to generalize the existing suggest_function_pointers function and also make sure it has enough information to understand situations like this is better than adding more logic to the compiler which will likely need to eventually be deduplicated in the future.

[mu001999]

r? @compiler-errors