Closed
Description
Summary
In the code below, Clippy's suggested "equivalent" Clone implementation regresses performance.
Given the API of this type, there is no reason for the Clone impl to memcpy any bytes. It can return a new uninit buffer, for free. The original clone() call compiles to 0 machine instructions. Clippy's suggested clone() implementation compiles to multiple instructions of redundant copying that cannot be optimized out.
Could Clippy identify the case of a type whose contents consist solely of MaybeUninit, and avoid triggering incorrect_clone_impl_on_copy_type in that case?
Lint Name
incorrect_clone_impl_on_copy_type
Reproducer
use std::mem::MaybeUninit;
pub struct Buffer {
bytes: [MaybeUninit<u8>; 24],
}
impl Buffer {
#[inline]
pub fn new() -> Self {
let bytes = [MaybeUninit::<u8>::uninit(); 24];
Buffer { bytes }
}
pub fn asdf(&mut self) -> &str {
todo!("init and return slice of buffer")
}
}
impl Copy for Buffer {}
impl Clone for Buffer {
#[inline]
fn clone(&self) -> Self {
Buffer::new()
}
}error: incorrect implementation of `clone` on a `Copy` type
--> src/main.rs:23:29
|
23 | fn clone(&self) -> Self {
| _____________________________^
24 | | Buffer::new()
25 | | }
| |_____^ help: change this to: `{ *self }`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#incorrect_clone_impl_on_copy_type
= note: `#[deny(clippy::incorrect_clone_impl_on_copy_type)]` on by defaultVersion
rustc 1.72.0-nightly (839e9a6e1 2023-07-02)
binary: rustc
commit-hash: 839e9a6e1210934fd24b15548b811a97c77138fc
commit-date: 2023-07-02
host: x86_64-unknown-linux-gnu
release: 1.72.0-nightly
LLVM version: 16.0.5
Additional Labels
No response