Variable shadowing
A local or parameter hides a state variable, so writes go to the wrong place.
What it is
When a function parameter or local variable shares a name with a state variable or an inherited member, the innermost declaration wins. An assignment intended for storage writes to a local that is discarded when the call ends.
Why it matters
State that appears to be updated never changes. In constructors and initialisers this is how an owner ends up unset, leaving the contract unadministrable or open to being claimed.
How to fix it
- Enable the compiler warning for shadowed declarations and treat it as an error.
- Adopt a naming convention that separates storage from locals — a leading underscore on parameters is the usual one.
How it is detected
Every audit on EVM Smart Audit checks for SWC-119 and reports it as passed or flagged in the standards coverage grid — so the report tells you it was checked even when nothing was found. See the detector suite for what else runs alongside it, or the full database for the other 21 checks.
Check your contract for variable shadowing
The engine runs this check and 21 others on every audit, and shows what passed as well as what failed.
Start audit