feat(unnecessary_fold): lint on folds with Add::add/Mul::mul

[ada4a]

Resurrects #13475

changelog: [unnecessary_fold]: lint on folds with Add::add/Mul::mul

[rustbot]

r? @Jarcho

rustbot has assigned @Jarcho.
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

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[ada4a]

@rustbot ready

[Jarcho]

What is this supposed to be checking for? The return type of a function must be a fully defined type.

[ada4a]

What is this supposed to be checking for?

Opaque types (like impl Add/Mul, see {add,mul}_turbofish_necessary), and generic types with trait bounds (something like fn sum<T: Add>(ts: &[T]) -> T), it seems

[Jarcho]

Can you change it to checking for opaque types then. Ty::walk will get you all the types you need to check.

The type of generic parameters can't be changed by inference so you can ignore those.

[ada4a]

The type of generic parameters can't be changed by inference

I think they can, if you replace fn foo() -> impl Add with fn foo<T: Add>() -> T

[Jarcho]

Those aren't the same thing. In fn foo<T>() -> T has the return type determined by the caller; inside the body it must be the abstract type T. With -> impl Trait the return type is determined by the callee with the actual type inferred from whatever the body returns.

[ada4a]

Ty::walk will get you all the types you need to check

Do you think descending into the generics is necessary, given that .sum()/.product() usually return primitive types? Though I guess nothing would stop an external implementation of Add/Mul from doing something like that...

[Jarcho]

Sum and Product are implemented for Option and Result, so yes.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.