rust-lang / rust-lang/rust-clippy
Whether or not the `drain_collect` lint suggestion is an improvement is context dependent
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 13.5k
- Forks
- 2.2k
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 32
Description
Description
The drain_collect lint will currently flag code like this:
fn method(values: &mut Vec<u8>) -> Vec<u8> {
values.drain(..).collect()
}
With:
warning: you seem to be trying to move all elements into a new `Vec`
--> src/main.rs:2:5
|
2 | values.drain(..).collect()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider using `mem::take`: `std::mem::take(values)`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#drain_collect
= note: `#[warn(clippy::drain_collect)]` on by default
Since this is marked as a perf hint, it's expected that the change has a different behavior than the original code. However, whether or not the proposed change is an improvement is in my mind too context dependent to be a default suggestion.
If for example values is a collection that is re-used explicitly to make use of its max allocated size, it might in the long run lead to more allocations swapping it than draining it would have.
This might mean that the label of MaybeIncorrect is more appropriate than MachineApplicable.
Version
rustc 1.76.0 (07dca489a 2024-02-04)
binary: rustc
commit-hash: 07dca489ac2d933c78d3c5158e3f43beefeb02ce
commit-date: 2024-02-04
host: x86_64-pc-windows-msvc
release: 1.76.0
LLVM version: 17.0.6
Additional Labels
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the drain_collect lint implementation and its diagnostic applicability handling, then inspect the lint's existing tests if available. Confirm whether this context-dependent performance suggestion should use MaybeIncorrect rather than MachineApplicable, and add or adjust coverage so the emitted applicability matches the decision.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100