Clippy lints / Style
Clippy lint · Style · checked with Clippy 0.1.99
clippy::toplevel_ref_arg: `ref` directly on a function parameter does not prevent taking ownership of the passed argument. Consider using a reference type instead
What it meansChecks for function arguments and let bindings denoted as ref. It is in the style group and warns by default.
What you see
warning: `ref` directly on a function parameter does not prevent taking ownership of the passed argument. Consider using a reference type instead --> main.rs:3:8 | 3 | fn foo(ref _x: u8) {} | ^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#toplevel_ref_arg = note: `#[warn(clippy::toplevel_ref_arg)]` on by default
Real output of Clippy 0.1.99 (Rust 1.99) on the example below. Names and line numbers in yours will differ.
Does it matter?
The ref declaration makes the function take an owned value, but turns the argument into a reference (which means that the value is destroyed when exiting the function). This adds not much value: either take a reference type, or take an owned value and create references in the body. For let bindings, let x = &foo; is preferred over let ref x = foo. The type of x is more obvious with the former.
Code that works but is not idiomatic Rust. 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
fn foo(ref _x: u8) {}
Write this instead
fn foo(_x: &u8) {}
Turn it off, or on
Allow it where it does not fit your code, as narrowly as you can:
On one item
#[allow(clippy::toplevel_ref_arg)]
fn my_function() { /* ... */ }Whole crate (Cargo.toml)
[lints.clippy]
toplevel_ref_arg = "allow"One run
cargo clippy -- -A clippy::toplevel-ref-argThe [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.
Clippy's own documentation
What it does
Checks for function arguments and let bindings denoted as
ref.
Why is this bad?
The ref declaration makes the function take an owned
value, but turns the argument into a reference (which means that the value
is destroyed when exiting the function). This adds not much value: either
take a reference type, or take an owned value and create references in the
body.
For let bindings, let x = &foo; is preferred over let ref x = foo. The
type of x is more obvious with the former.
Known problems
If the argument is dereferenced within the function,
removing the ref will lead to errors. This can be fixed by removing the
dereferences, e.g., changing *x to x within the function.
Example
fn foo(ref _x: u8) {}
Use instead:
fn foo(_x: &u8) {}
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- needless_returnunneeded `return` statement
- new_without_defaultChecks for public types with a pub fn new() -> Self method and no implementation of Default
- len_zeroChecks for getting the length of something via .len() just to compare to zero, and suggests using .is_empty() where applicable
- tabs_in_doc_commentsusing tabs in doc comments is not recommended
- to_digit_is_someChecks for .to_digit(..).is_some() on chars
- to_string_trait_impldirect implementation of `ToString`
- trim_split_whitespacefound call to `str::trim` before `str::split_whitespace`
- unnecessary_fallible_conversionsuse of a fallible conversion when an infallible one could be used
- unnecessary_foldthis `.fold` can be written more succinctly using another method
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::needless_returnunneeded `return` statementRead it next →Did this answer your question?