lint on unnecessary collections

[bend-n]

lints on

fn squares() -> Vec<(u8, u8)> {
 (0..8u8)
   .flat_map(|x| (0..8).map(move |y| (x, y)))
   .collect::<Vec<_>>()
}

changelog: [unnecessary_collect]: create lint

see also #clippy > linting on vector returns where return is collected

name can be bikeshed

[rustbot]

r? @llogiq

rustbot has assigned @llogiq. They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[github-actions[bot]]

Lintcheck changes for 7e91e188c5209d26fa135c1cf525b34452c116a6

Lint	Added	Removed	Changed
clippy::unnecessary_collect	36	0	0

This comment will be updated if you push new changes

[rustbot]

Some changes occurred in clippy_lints/src/doc

cc @notriddle

[rustbot]

:umbrella: The latest upstream changes (possibly 0a2eeceefcd99185643f7659ce25b6376749c271) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rustbot]

:umbrella: The latest upstream changes (possibly c48592eb49d984aee2f813336e2363798e004119) made this pull request unmergeable. Please resolve the merge conflicts.

[llogiq]

I personally think that the lint as is probably fits a restriction lint best (and should be documented to only show possible optimization opportunities), however, with an additional check if the result of that method ever is manipulated other than iterating it, and only linting if that's not the case would make the lint vastly more useful.

However, I don't think this PR needs to do the extension.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.