Impl trait lifetime mismatch

What it does

Detect impl items where the lifetimes do not match the trait item definition. I believe this can be more specifically described as having "stricter" lifetime requirements than the trait item definition.

Categories (optional)

• Kind: style

What is the advantage of the recommended code over the original code

Inconsistency between the trait and impl is confusing and less self-documenting. Also it may lead to preventable lifetime errors. Also, since the lifetime is already named and available in the impl block, it seems appropriate to use it wherever applicable.

Drawbacks

It is more convenient to elide lifetimes if the particular implementation allows it.

Example

trait Foo<'a> {
    fn hi(a: &'a str, b: &'a str);
}

struct Bar;
struct Baz;

impl<'a> Foo<'a> for Bar {
    // here the trait lifetime is unused
    fn hi(_: &str, _: &str) {
        unimplemented!()
    }
}

impl<'a> Foo<'a> for Baz {
    // here different lifetime semantics are applied
    fn hi<'b>(_: &'b str, _: &'b str) {
        unimplemented!()
    }
}

Could be written as:

impl<'a> Foo<'a> for Bar {
    fn hi(_: &'a str, _: &'a str) {
        unimplemented!()
    }
}

The issue names no files, tests, or entry points. Start by examining rust-clippy's existing lint infrastructure and how trait and impl item lifetimes are compared; done means the lint identifies the unused or stricter lifetime cases shown in the examples and provides regression coverage for them.