Clippy lint · Performance · checked with Clippy 0.1.99

clippy::cloned_ref_to_slice_refs: Checks for slice references with cloned references such as &[f.clone()]

What it meansChecks for slice references with cloned references such as &[f.clone()]. It is in the performance group and warns by default.

Does it matter?

A reference does not need to be owned in order to be used as a slice.

Code that could be written to run faster. Warns by default.

How to fix it

Clippy can fix this one for you: run cargo clippy --fix (add --allow-dirty if you have uncommitted changes). Review the diff before you commit.

Flagged

let data = 10;
let data_ref = &data;
take_slice(&[data_ref.clone()]);

Write this instead

use std::slice;
let data = 10;
let data_ref = &data;
take_slice(slice::from_ref(data_ref));

Turn it off, or on

Allow it where it does not fit your code, as narrowly as you can:

On one item

#[allow(clippy::cloned_ref_to_slice_refs)]
fn my_function() { /* ... */ }

Whole crate (Cargo.toml)

[lints.clippy]
cloned_ref_to_slice_refs = "allow"

One run

cargo clippy -- -A clippy::cloned-ref-to-slice-refs

The [lints] table needs Rust 1.74 or newer. In a workspace, put it under [workspace.lints.clippy] and add [lints] workspace = true to each member.

Performancegroup

warndefault level

yesfixed by cargo clippy --fix

1.89.0added in Rust

Clippy's own documentation

What it does

Checks for slice references with cloned references such as &[f.clone()].

Why is this bad

A reference does not need to be owned in order to be used as a slice.

Known problems

This lint does not know whether or not a clone implementation has side effects.

Example

let data = 10;
let data_ref = &data;
take_slice(&[data_ref.clone()]);

Use instead:

use std::slice;
let data = 10;
let data_ref = &data;
take_slice(slice::from_ref(data_ref));

From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.

Up next

Also worth your time

Did this answer your question?