diff options
| author | Samuel Tardieu <sam@rfc1149.net> | 2022-12-01 17:58:28 +0100 |
|---|---|---|
| committer | Samuel Tardieu <sam@rfc1149.net> | 2022-12-17 16:20:43 +0100 |
| commit | af39a8a4a82001b38e2b6c0d391d1aa76740ec4b (patch) | |
| tree | 45a585d5af25276723752de376c56ba600307704 /tests/codegen/src-hash-algorithm/src-hash-algorithm-sha1.rs | |
| parent | 38fce1235a024078d996a52d7f89692ea3005268 (diff) | |
| download | rust-af39a8a4a82001b38e2b6c0d391d1aa76740ec4b.tar.gz rust-af39a8a4a82001b38e2b6c0d391d1aa76740ec4b.zip | |
Identify more cases of useless `into_iter()` calls
If the type of the result of a call to `IntoIterator::into_iter()` and the type of the receiver are the same, then the receiver implements `Iterator` and `into_iter()` is the identity function. The call to `into_iter()` may be removed in all but two cases: - If the receiver implements `Copy`, `into_iter()` will produce a copy of the receiver and cannot be removed. For example, `x.into_iter().next()` will not advance `x` while `x.next()` will. - If the receiver is an immutable local variable and the call to `into_iter()` appears in a larger expression, removing the call to `into_iter()` might cause mutability issues. For example, if `x` is an immutable local variable, `x.into_iter().next()` will compile while `x.next()` will not as `next()` receives `&mut self`.
Diffstat (limited to 'tests/codegen/src-hash-algorithm/src-hash-algorithm-sha1.rs')
0 files changed, 0 insertions, 0 deletions
