Suggest `#[inline]`ing `Iterator::next` on concrete types

What it does

Inspired by https://github.com/rust-lang/rust/pull/94776/files#diff-8af5d8e765e2bed4c60f695e2779241af1f313dfecd28f5e9059c30c93fa0311R114

Very often, the performance of iterators depends on Iterator::next getting inlined.

That's usually not a problem, because iterators are often generic, and thus the monomorphization is available to be inlined.

However, non-generic iterators can't cross-crate inline by default, so it would be good to suggest marking them #[inline].

Lint Name

non_inlined_concrete_iterator

Category

perf

Advantage

Allows for the possibility of improved optimizations at the call site.

Drawbacks

All the usual drawbacks of inlining apply, like potentially slower compilation or increased binary size.

This might not be necessary for iterators not exported from their crate.

Example

impl Iterator for EscapeDefault {
    type Item = u8;

    fn next(&mut self) -> Option<u8> {
        self.range.next().map(|i| self.data[i as usize])
    }
}

Could be written as:

impl Iterator for EscapeDefault {
    type Item = u8;

    #[inline]
    fn next(&mut self) -> Option<u8> {
        self.range.next().map(|i| self.data[i as usize])
    }
}

Review the proposed non_inlined_concrete_iterator lint and its EscapeDefault example first. Establish how the lint should identify concrete iterator implementations and what diagnostic should recommend; done means the lint's behavior matches the stated example and accounts for the listed inlining drawbacks.