New lint suggestion: `iter_copied_too_late`

What it does

This is the proposal of a Clippy perf lint to address the performance issue cited here: https://github.com/rust-lang/rust/issues/106539

It suggests moving .copied() in an iterator chain earlier if the resulting type would be a value type T anyways instead of &T.

This may result in confusing advice since it contradicts iter_overeager_cloned. However, to clone vs. copying things is genuinely different, so more experienced Rust users won't be too surprised.

Lint Name

iter_copied_too_late

Category

perf

Advantage

Especially with simple scalar types, this results in the usage of vector instructions when lowered to LLVM IR.

Drawbacks

Some false positives:

• if copying only removed a layer of indirection, from &&T to &T instead of &T to T
• type is too complex to vectorize (safest if it is a primitive or newtype of one)
• random other niche cases where this doesn't actually improve performance can happen also

Example

pub fn scalarized_max<T: Ord + Copy>(a: &[T]) -> Option<T> {
    a.iter().max().copied()
}

This will typically drop to scalar code because LLVM can't immediately see that it can just dereference everything and reason about simple scalar types instaed. It could be written as:

pub fn vectorized_max<T: Ord + Copy>(a: &[T]) -> Option<T> {
    a.iter().copied().max()
}

Start by locating the existing Clippy iterator performance lints and their tests; no specific files or entry points are named in the issue. Compare the proposed iter_copied_too_late behavior with iter_overeager_cloned, then add coverage for the iter().max().copied() example and verify that the suggested rewrite is emitted without inappropriate false positives.