Lint for use of operator's trait's method instead of the operator itself

What it does

If somebody calls std::ops::Add::add(foo, bar), suggest foo + bar.

In my experience with Exercism, beginners often find the API they need in the trait, not realizing its relation to the operator. Naming the trait method requires an import and is usually unnecessarily verbose, so we might want to lint against it.

Categories

• Kind: clippy::style

Drawbacks

None.

Example

use std::ops::Add;
use chrono::{DateTime, Duration, Utc};

pub fn time_travel(now: DateTime<Utc>, how_long: Duration)
    -> DateTime<Utc>
{
    now.add(how_long)
}

Could be written as:

use std::ops::Add;
use chrono::{DateTime, Duration, Utc};

pub fn time_travel(now: DateTime<Utc>, how_long: Duration)
    -> DateTime<Utc>
{
    now + how_long
}

Note

This is a follow-up to #5679, which described a similar issue for FromIterator, and the case of operator traits got mentioned in the comments. The PR that solved the FromIterator case didn't handle this case, so i'm opening a separate issue.

Start by reading the related #5679 issue and the implementation that handled its FromIterator case, then locate the corresponding Clippy lint and test structure. Add coverage for operator trait method calls such as Add::add and verify that the lint suggests the equivalent operator expression.