Repository navigation
Lint function inputs being shadowed with a mutable variable #17868
Description
What it does
If a variable is taken as input immutably, and then shadowed with let mut, suggest binding in the function arguments with mut instead.
Advantage
Cleanliness, mostly.
Drawbacks
N/A?
Example
fn mut_shadow(x: u32) -> u32 {
let mut x = x;
x++;
return x;
}Could be written as:
fn mut_shadow(mut x: u32) -> u32 {
x += 1;
return x;
}Comparison with existing lints
Semi related to #11704, but for function arguments. Roll both into one issue?
Additional Context
An argument being taken in that's Copy or Clone doesn't need to really worry about messing with the caller, since the variable either copied or moved into the function's scope and the caller doesn't have to worry about it from that point on.
Activity
mi2ebi commentedon Oct 12, 2026
what if you really don't want to mutate x? that's true more often for me at least
Fulgen301 commentedon Oct 12, 2026
I'm not convinced this adds cleanliness in all cases. Even ignoring misunderstandings what a mutable parameter means, like the referenced PR originally had, there are reasons why keeping
mutout of the function header might be preferred:mutwould add more noise that would get lost.mutwould add differences to the original signature.let mut x = x;binding in the body - the linked PR originally had a comment explaining the meaning ofmutby that parameter; while the explanation was incorrect, it serves as an indicator that the intent may not be clear enough to lint against, at least by default.orowith2os commentedon Oct 12, 2026
Then don't bind it as
mut.let mut x = x;isn't the same aslet x = &mut x, which isn't the same aslet mut x = &mut x;, and I would expect somebody to know this when writing Rust. I don't see this as any different from usinglet.mi2ebi commentedon Oct 12, 2026
should've clarified, i may want to not mutate the parameter x but still want to make a
let mut x = x;