Clippy lints / Complexity
Clippy lint · Complexity · checked with Clippy 0.1.99
clippy::only_used_in_recursion: parameter is only used in recursion
What it meansChecks for arguments that are only used in recursion with no side-effects. It is in the complexity group and warns by default.
What you see
warning: parameter is only used in recursion --> main.rs:3:16 | 3 | fn f(a: usize, b: usize) -> usize { | ^ help: if this is intentional, prefix it with an underscore: `_b` | note: parameter used here --> main.rs:7:18 | 7 | f(a - 1, b + 1) | ^ = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#only_used_in_recursion = note: `#[warn(clippy::only_used_in_recursion)]` 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?
It could contain a useless calculation and can make function simpler. The arguments can be involved in calculations and assignments but as long as the calculations have no side-effects (function calls or mutating dereference) and the assigned variables are also only in recursion, it is useless.
Code that does something simple in a complicated way. Warns by default.
How to fix it
Clippy does not fix this one automatically (its suggestion may change behaviour, so it only shows it). Change the code by hand:
Flagged
fn f(a: usize, b: usize) -> usize {
if a == 0 {
1
} else {
f(a - 1, b + 1)
}
}
Write this instead
fn f(a: usize) -> usize {
if a == 0 {
1
} else {
f(a - 1)
}
}
Turn it off, or on
Allow it where it does not fit your code, as narrowly as you can:
On one item
#[allow(clippy::only_used_in_recursion)]
fn my_function() { /* ... */ }Whole crate (Cargo.toml)
[lints.clippy]
only_used_in_recursion = "allow"One run
cargo clippy -- -A clippy::only-used-in-recursionThe [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 arguments that are only used in recursion with no side-effects.
Why is this bad?
It could contain a useless calculation and can make function simpler.
The arguments can be involved in calculations and assignments but as long as the calculations have no side-effects (function calls or mutating dereference) and the assigned variables are also only in recursion, it is useless.
Example
fn f(a: usize, b: usize) -> usize {
if a == 0 {
1
} else {
f(a - 1, b + 1)
}
}
Use instead:
fn f(a: usize) -> usize {
if a == 0 {
1
} else {
f(a - 1)
}
}
Known problems
Too many code paths in the linting code are currently untested and prone to produce false positives or are prone to have performance implications.
In some cases, this would not catch all useless arguments.
fn foo(a: usize, b: usize) -> usize {
let f = |x| x + 1;
if a == 0 {
1
} else {
foo(a - 1, f(b))
}
}
For example, the argument b is only used in recursion, but the lint would not catch it.
List of some examples that can not be caught:
- binary operation of non-primitive types
- closure usage
- some
breakrelative operations - struct pattern binding
Also, when you recurse the function name with path segments, it is not possible to detect.
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- too_many_argumentsChecks for functions with too many parameters
- clone_on_copyusing `clone` on type `u64` which implements the `Copy` trait
- type_complexityChecks for types used in structs, parameters and let declarations above a certain complexity threshold
- neg_cmp_op_on_partial_ordthe use of negated comparison operators on partially ordered types produces code that is hard to read and refactor, please consider using the `partial_cmp` method instead, to make it clear that the two values could be incomparable
- no_effectstatement with no effect
- nonnull_unchecked_on_box_ptruse of `NonNull::new_unchecked` with `Box::into_raw`
- option_as_ref_derefChecks for usage of _.as_ref().map(Deref::deref) or its aliases (such as String::as_str)
- option_filter_map`filter` for `Some` followed by `unwrap`
- option_map_unit_fnChecks for usage of option.map(f) where f is a function or closure that returns the unit type ()
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::too_many_argumentsChecks for functions with too many parametersRead it next →Did this answer your question?