Suggest using `!`/`Infallibe` in trait implementations with a result type.

When a user implements a trait, where the function signature returns a result (like in FromStr or TryFrom) and the function body doesn't return an error, the lint should suggest to use Infallible or ! (! isn't stabilized yet, https://github.com/rust-lang/rust/issues/35121).

What it does

Checks for trait implementations, where the function signature returns a Result<T, E> and the body doesn't return the error-variant.

Why is this bad

Using ! or an enum like Infallible , that can not be constructed, allows the compiler to better optimize the code (similar to unreachable!).

Example

use std::str::FromStr;

struct ExampleStruct(String);

impl FromStr for ExampleStruct {
    type Err = Box<dyn std::error::Error>;

    fn from_str(input: &str) -> Result<Self, Self::Err> {
        Ok(Self(input.to_string()))
    }
}

better

use std::str::FromStr;

struct ExampleStruct(String);

impl FromStr for ExampleStruct {
    type Err = std::convert::Infallible;

    fn from_str(input: &str) -> Result<Self, Self::Err> {
        Ok(Self(input.to_string()))
    }
}

even better (! isn't stabilized yet)

use std::str::FromStr;

struct ExampleStruct(String);

impl FromStr for ExampleStruct {
    type Err = !;

    fn from_str(input: &str) -> Result<Self, Self::Err> {
        Ok(Self(input.to_string()))
    }
}

This lint could be generalized to lint against all kind of functions like

struct ExampleStruct(String);

impl ExampleStruct {
    pub fn as_str(&self) -> Result<&str, Box<dyn std::error::Error> {
        Ok(self.0.as_str())
    }
}

but some of them might be intentional, to not break future versions.

In the above example it might be better to drop the Result type, which cannot be done for trait implementations. (hence the lint)

Start by reviewing the proposed FromStr and TryFrom trait-implementation examples and the distinction between Infallible and the unstable ! type. Define the lint's supported scope, including whether it should cover only trait implementations or general Result-returning functions, and consider the suggested behavior complete when the intended cases are specified without changing potentially intentional APIs.