Clippy Lints Total number: 794

What it does

Checks for usage of items through absolute paths, like std::env::current_dir.

Why restrict this?

Many codebases have their own style when it comes to importing, but one that is seldom used is using absolute paths everywhere. This is generally considered unidiomatic, and you should add a use statement.

The default maximum segments (2) is pretty strict, you may want to increase this in clippy.toml.

Note: One exception to this is code from macro expansion - this does not lint such cases, as using absolute paths is the proper way of referencing items in one.

Known issues

There are currently a few cases which are not caught by this lint:

• Macro calls. e.g. path::to::macro!()
• Derive macros. e.g. #[derive(path::to::macro)]
• Attribute macros. e.g. #[path::to::macro]

Example

let x = std::f64::consts::PI; 

Use any of the below instead, or anything else:

use std::f64; use std::f64::consts; use std::f64::consts::PI; let x = f64::consts::PI; let x = consts::PI; let x = PI; use std::f64::consts as f64_consts; let x = f64_consts::PI; 

Configuration

• absolute-paths-allowed-crates: Which crates to allow absolute paths from

  (default: [])

• absolute-paths-max-segments: The maximum number of segments a path can have before being linted, anything above this will be linted.

  (default: 2)

What it does

Checks for comparisons where one side of the relation is either the minimum or maximum value for its type and warns if it involves a case that is always true or always false. Only integer and boolean types are checked.

Why is this bad?

An expression like min <= x may misleadingly imply that it is possible for x to be less than the minimum. Expressions like max < x are probably mistakes.

Known problems

For usize the size of the current compile target will be assumed (e.g., 64 bits on 64 bit systems). This means code that uses such a comparison to detect target pointer width will trigger this lint. One can use mem::sizeof and compare its value or conditional compilation attributes like #[cfg(target_pointer_width = "64")] .. instead.

Example

let vec: Vec<isize> = Vec::new(); if vec.len() <= 0 {} if 100 > i32::MAX {} 

What it does

Finds items imported through alloc when available through core.

Why restrict this?

Crates which have no_std compatibility and may optionally require alloc may wish to ensure types are imported from core to ensure disabling alloc does not cause the crate to fail to compile. This lint is also useful for crates migrating to become no_std compatible.

Known problems

The lint is only partially aware of the required MSRV for items that were originally in std but moved to core.

Example

use alloc::slice::from_ref; 

Use instead:

use core::slice::from_ref; 

What it does

Checks for usage of the #[allow] attribute and suggests replacing it with the #[expect] attribute (See RFC 2383)

This lint only warns outer attributes (#[allow]), as inner attributes (#![allow]) are usually used to enable or disable lints on a global scale.

Why is this bad?

#[expect] attributes suppress the lint emission, but emit a warning, if the expectation is unfulfilled. This can be useful to be notified when the lint is no longer triggered.

Example

#[allow(unused_mut)] fn foo() -> usize { let mut a = Vec::new(); a.len() } 

Use instead:

#[expect(unused_mut)] fn foo() -> usize { let mut a = Vec::new(); a.len() } 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for attributes that allow lints without a reason.

Why restrict this?

Justifying each allow helps readers understand the reasoning, and may allow removing allow attributes if their purpose is obsolete.

Example

#![allow(clippy::some_lint)] 

Use instead:

#![allow(clippy::some_lint, reason = "False positive rust-lang/rust-clippy#1002020")] 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for ranges which almost include the entire range of letters from ‘a’ to ‘z’ or digits from ‘0’ to ‘9’, but don’t because they’re a half open range.

Why is this bad?

This ('a'..'z') is almost certainly a typo meant to include all letters.

Example

let _ = 'a'..'z'; 

Use instead:

let _ = 'a'..='z'; 

Past names

• almost_complete_letter_range

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for foo = bar; bar = foo sequences.

Why is this bad?

This looks like a failed attempt to swap.

Example

a = b; b = a; 

If swapping is intended, use swap() instead:

std::mem::swap(&mut a, &mut b); 

What it does

Checks for floating point literals that approximate constants which are defined in std::f32::consts or std::f64::consts, respectively, suggesting to use the predefined constant.

Why is this bad?

Usually, the definition in the standard library is more precise than what people come up with. If you find that your definition is actually more precise, please file a Rust issue.

Example

let x = 3.14; let y = 1_f64 / x; 

Use instead:

let x = std::f32::consts::PI; let y = std::f64::consts::FRAC_1_PI; 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Confirms that items are sorted in source files as per configuration.

Why restrict this?

Keeping a consistent ordering throughout the codebase helps with working as a team, and possibly improves maintainability of the codebase. The idea is that by defining a consistent and enforceable rule for how source files are structured, less time will be wasted during reviews on a topic that is (under most circumstances) not relevant to the logic implemented in the code. Sometimes this will be referred to as “bikeshedding”.

The content of items with a representation clause attribute, such as #[repr(C)] will not be checked, as the order of their fields or variants might be dictated by an external API (application binary interface).

Default Ordering and Configuration

As there is no generally applicable rule, and each project may have different requirements, the lint can be configured with high granularity. The configuration is split into two stages:

1. Which item kinds that should have an internal order enforced.
2. Individual ordering rules per item kind.

The item kinds that can be linted are:

• Module (with customized groupings, alphabetical within - configurable)
• Trait (with customized order of associated items, alphabetical within)
• Enum, Impl, Struct (purely alphabetical)

Module Item Order

Due to the large variation of items within modules, the ordering can be configured on a very granular level. Item kinds can be grouped together arbitrarily, items within groups will be ordered alphabetically. The following table shows the default groupings:

The groups’ names are arbitrary and can be changed to suit the conventions that should be enforced for a specific project.

All item kinds must be accounted for to create an enforceable linting rule set. Following are some example configurations that may be useful.

Example: module inclusions and use statements to be at the top

module-item-order-groupings = [ [ "modules", [ "extern_crate", "mod", "foreign_mod" ], ], [ "use", [ "use", ], ], [ "everything_else", [ "macro", "global_asm", "static", "const", "ty_alias", "enum", "struct", "union", "trait", "trait_alias", "impl", "fn", ], ], ] 

Example: only consts and statics should be alphabetically ordered

It is also possible to configure a selection of module item groups that should be ordered alphabetically. This may be useful if for example statics and consts should be ordered, but the rest should be left open.

module-items-ordered-within-groupings = ["UPPER_SNAKE_CASE"] 

Known Problems

Performance Impact

Keep in mind, that ordering source code alphabetically can lead to reduced performance in cases where the most commonly used enum variant isn’t the first entry anymore, and similar optimizations that can reduce branch misses, cache locality and such. Either don’t use this lint if that’s relevant, or disable the lint in modules or items specifically where it matters. Other solutions can be to use profile guided optimization (PGO), post-link optimization (e.g. using BOLT for LLVM), or other advanced optimization methods. A good starting point to dig into optimization is cargo-pgo.

Lints on a Contains basis

The lint can be disabled only on a “contains” basis, but not per element within a “container”, e.g. the lint works per-module, per-struct, per-enum, etc. but not for “don’t order this particular enum variant”.

Module documentation

Module level rustdoc comments are not part of the resulting syntax tree and as such cannot be linted from within check_mod. Instead, the rustdoc::missing_documentation lint may be used.

Module Tests

This lint does not implement detection of module tests (or other feature dependent elements for that matter). To lint the location of mod tests, the lint items_after_test_module can be used instead.

Example

trait TraitUnordered { const A: bool; const C: bool; const B: bool; type SomeType; fn a(); fn c(); fn b(); } 

Use instead:

trait TraitOrdered { const A: bool; const B: bool; const C: bool; type SomeType; fn a(); fn b(); fn c(); } 

Configuration

• module-item-order-groupings: The named groupings of different source item kinds within modules.

  (default: [["modules", ["extern_crate", "mod", "foreign_mod"]], ["use", ["use"]], ["macros", ["macro"]], ["global_asm", ["global_asm"]], ["UPPER_SNAKE_CASE", ["static", "const"]], ["PascalCase", ["ty_alias", "enum", "struct", "union", "trait", "trait_alias", "impl"]], ["lower_snake_case", ["fn"]]])

• module-items-ordered-within-groupings: Whether the items within module groups should be ordered alphabetically or not.

This option can be configured to “all”, “none”, or a list of specific grouping names that should be checked (e.g. only “enums”).

(default: "none")

• source-item-ordering: Which kind of elements should be ordered internally, possible values being enum, impl, module, struct, trait.

  (default: ["enum", "impl", "module", "struct", "trait"])

• trait-assoc-item-kinds-order: The order of associated items in traits.

  (default: ["const", "type", "fn"])

What it does.

This lint warns when you use Arc with a type that does not implement Send or Sync.

Why is this bad?

Arc<T> is a thread-safe Rc<T> and guarantees that updates to the reference counter use atomic operations. To send an Arc<T> across thread boundaries and share ownership between multiple threads, T must be both Send and Sync, so either T should be made Send + Sync or an Rc should be used instead of an Arc.

Example

 fn main() { // This is fine, as `i32` implements `Send` and `Sync`. let a = Arc::new(42); // `RefCell` is `!Sync`, so either the `Arc` should be replaced with an `Rc` // or the `RefCell` replaced with something like a `RwLock` let b = Arc::new(RefCell::new(42)); } 

What it does

Checks any kind of arithmetic operation of any type.

Operators like +, -, * or << are usually capable of overflowing according to the Rust Reference, or can panic (/, %).

Known safe built-in types like Wrapping or Saturating, floats, operations in constant environments, allowed types and non-constant operations that won’t overflow are ignored.

Why restrict this?

For integers, overflow will trigger a panic in debug builds or wrap the result in release mode; division by zero will cause a panic in either mode. As a result, it is desirable to explicitly call checked, wrapping or saturating arithmetic methods.

Example

// `n` can be any number, including `i32::MAX`. fn foo(n: i32) -> i32 { n + 1 } 

Third-party types can also overflow or present unwanted side-effects.

Example

use rust_decimal::Decimal; let _n = Decimal::MAX + Decimal::MAX; 

Past names

• integer_arithmetic

Configuration

• arithmetic-side-effects-allowed: Suppress checking of the passed type names in all types of operations.

If a specific operation is desired, consider using arithmetic_side_effects_allowed_binary or arithmetic_side_effects_allowed_unary instead.

Example

arithmetic-side-effects-allowed = ["SomeType", "AnotherType"] 

Noteworthy

A type, say SomeType, listed in this configuration has the same behavior of ["SomeType" , "*"], ["*", "SomeType"] in arithmetic_side_effects_allowed_binary.

(default: [])

• arithmetic-side-effects-allowed-binary: Suppress checking of the passed type pair names in binary operations like addition or multiplication.

Supports the “*” wildcard to indicate that a certain type won’t trigger the lint regardless of the involved counterpart. For example, ["SomeType", "*"] or ["*", "AnotherType"].

Pairs are asymmetric, which means that ["SomeType", "AnotherType"] is not the same as ["AnotherType", "SomeType"].

Example

arithmetic-side-effects-allowed-binary = [["SomeType" , "f32"], ["AnotherType", "*"]] 

(default: [])

• arithmetic-side-effects-allowed-unary: Suppress checking of the passed type names in unary operations like “negation” (-).

Example

arithmetic-side-effects-allowed-unary = ["SomeType", "AnotherType"] 

(default: [])

What it does

Checks for usage of as conversions.

Note that this lint is specialized in linting every single use of as regardless of whether good alternatives exist or not. If you want more precise lints for as, please consider using these separate lints:

• clippy::cast_lossless
• clippy::cast_possible_truncation
• clippy::cast_possible_wrap
• clippy::cast_precision_loss
• clippy::cast_sign_loss
• clippy::char_lit_as_u8
• clippy::fn_to_numeric_cast
• clippy::fn_to_numeric_cast_with_truncation
• clippy::ptr_as_ptr
• clippy::unnecessary_cast
• invalid_reference_casting

There is a good explanation the reason why this lint should work in this way and how it is useful in this issue.

Why restrict this?

as conversions will perform many kinds of conversions, including silently lossy conversions and dangerous coercions. There are cases when it makes sense to use as, so the lint is Allow by default.

Example

let a: u32; ... f(a as u16); 

Use instead:

f(a.try_into()?); // or f(a.try_into().expect("Unexpected u16 overflow in f")); 

What it does

Checks for the usage of as *const _ or as *mut _ conversion using inferred type.

Why restrict this?

The conversion might include a dangerous cast that might go undetected due to the type being inferred.

Example

fn as_usize<T>(t: &T) -> usize { // BUG: `t` is already a reference, so we will here // return a dangling pointer to a temporary value instead &t as *const _ as usize } 

Use instead:

fn as_usize<T>(t: &T) -> usize { t as *const T as usize } 

What it does

Checks for the result of a &self-taking as_ptr being cast to a mutable pointer.

Why is this bad?

Since as_ptr takes a &self, the pointer won’t have write permissions unless interior mutability is used, making it unlikely that having it as a mutable pointer is correct.

Example

let mut vec = Vec::<u8>::with_capacity(1); let ptr = vec.as_ptr() as *mut u8; unsafe { ptr.write(4) }; // UNDEFINED BEHAVIOUR 

Use instead:

let mut vec = Vec::<u8>::with_capacity(1); let ptr = vec.as_mut_ptr(); unsafe { ptr.write(4) }; 

What it does

Checks for the usage of as _ conversion using inferred type.

Why restrict this?

The conversion might include lossy conversion or a dangerous cast that might go undetected due to the type being inferred.

The lint is allowed by default as using _ is less wordy than always specifying the type.

Example

fn foo(n: usize) {} let n: u16 = 256; foo(n as _); 

Use instead:

fn foo(n: usize) {} let n: u16 = 256; foo(n as usize); 

What it does

Checks for assert!(true) and assert!(false) calls.

Why is this bad?

Will be optimized out by the compiler or should probably be replaced by a panic!() or unreachable!()

Example

assert!(false) assert!(true) const B: bool = false; assert!(B) 

What it does

Checks for assert!(r.is_ok()) or assert!(r.is_err()) calls.

Why restrict this?

This form of assertion does not show any of the information present in the Result other than which variant it isn’t.

Known problems

The suggested replacement decreases the readability of code and log output.

Example

assert!(r.is_ok()); assert!(r.is_err()); 

Use instead:

r.unwrap(); r.unwrap_err(); 

What it does

Checks for a = a op b or a = b commutative_op a patterns.

Why is this bad?

These can be written as the shorter a op= b.

Known problems

While forbidden by the spec, OpAssign traits may have implementations that differ from the regular Op impl.

Example

let mut a = 5; let b = 0; // ... a = a + b; 

Use instead:

let mut a = 5; let b = 0; // ... a += b; 

What it does

Nothing. This lint has been deprecated

Deprecation reason

Compound operators are harmless and linting on them is not in scope for clippy.

What it does

Checks for code like foo = bar.clone();

Why is this bad?

Custom Clone::clone_from() or ToOwned::clone_into implementations allow the objects to share resources and therefore avoid allocations.

Example

struct Thing; impl Clone for Thing { fn clone(&self) -> Self { todo!() } fn clone_from(&mut self, other: &Self) { todo!() } } pub fn assign_to_ref(a: &mut Thing, b: Thing) { *a = b.clone(); } 

Use instead:

struct Thing; impl Clone for Thing { fn clone(&self) -> Self { todo!() } fn clone_from(&mut self, other: &Self) { todo!() } } pub fn assign_to_ref(a: &mut Thing, b: Thing) { a.clone_from(&b); } 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for async blocks that yield values of types that can themselves be awaited.

Why is this bad?

An await is likely missing.

Example

async fn foo() {} fn bar() { let x = async { foo() }; } 

Use instead:

async fn foo() {} fn bar() { let x = async { foo().await }; } 

What it does

Allows users to configure types which should not be held across await suspension points.

Why is this bad?

There are some types which are perfectly safe to use concurrently from a memory access perspective, but that will cause bugs at runtime if they are held in such a way.

Example

await-holding-invalid-types = [ # You can specify a type name "CustomLockType", # You can (optionally) specify a reason { path = "OtherCustomLockType", reason = "Relies on a thread local" } ] 

struct CustomLockType; struct OtherCustomLockType; async fn foo() { let _x = CustomLockType; let _y = OtherCustomLockType; baz().await; // Lint violation } 

Configuration

• await-holding-invalid-types: The list of types which may not be held across an await point.

  (default: [])

What it does

Checks for calls to await while holding a non-async-aware MutexGuard.

Why is this bad?

The Mutex types found in std::sync and parking_lot are not designed to operate in an async context across await points.

There are two potential solutions. One is to use an async-aware Mutex type. Many asynchronous foundation crates provide such a Mutex type. The other solution is to ensure the mutex is unlocked before calling await, either by introducing a scope or an explicit call to Drop::drop.

Known problems

Will report false positive for explicitly dropped guards (#6446). A workaround for this is to wrap the .lock() call in a block instead of explicitly dropping the guard.

Example

async fn foo(x: &Mutex<u32>) { let mut guard = x.lock().unwrap(); *guard += 1; baz().await; } async fn bar(x: &Mutex<u32>) { let mut guard = x.lock().unwrap(); *guard += 1; drop(guard); // explicit drop baz().await; } 

Use instead:

async fn foo(x: &Mutex<u32>) { { let mut guard = x.lock().unwrap(); *guard += 1; } baz().await; } async fn bar(x: &Mutex<u32>) { { let mut guard = x.lock().unwrap(); *guard += 1; } // guard dropped here at end of scope baz().await; } 

What it does

Checks for calls to await while holding a RefCell, Ref, or RefMut.

Why is this bad?

RefCell refs only check for exclusive mutable access at runtime. Holding a RefCell ref across an await suspension point risks panics from a mutable ref shared while other refs are outstanding.

Known problems

Will report false positive for explicitly dropped refs (#6353). A workaround for this is to wrap the .borrow[_mut]() call in a block instead of explicitly dropping the ref.

Example

async fn foo(x: &RefCell<u32>) { let mut y = x.borrow_mut(); *y += 1; baz().await; } async fn bar(x: &RefCell<u32>) { let mut y = x.borrow_mut(); *y += 1; drop(y); // explicit drop baz().await; } 

Use instead:

async fn foo(x: &RefCell<u32>) { { let mut y = x.borrow_mut(); *y += 1; } baz().await; } async fn bar(x: &RefCell<u32>) { { let mut y = x.borrow_mut(); *y += 1; } // y dropped here at end of scope baz().await; } 

What it does

Checks for incompatible bit masks in comparisons.

The formula for detecting if an expression of the type _ <bit_op> m <cmp_op> c (where <bit_op> is one of {&, |} and <cmp_op> is one of {!=, >=, >, !=, >=, >}) can be determined from the following table:

Why is this bad?

If the bits that the comparison cares about are always set to zero or one by the bit mask, the comparison is constant true or false (depending on mask, compared value, and operators).

So the code is actively misleading, and the only reason someone would write this intentionally is to win an underhanded Rust contest or create a test-case for this lint.

Example

if (x & 1 == 2) { } 

What it does

Checks for the usage of the to_be_bytes method and/or the function from_be_bytes.

Why restrict this?

To ensure use of little-endian or the target’s endianness rather than big-endian.

Example

let _x = 2i32.to_be_bytes(); let _y = 2i64.to_be_bytes(); 

What it does

Checks for usage of _.and_then(|x| Some(y)), _.and_then(|x| Ok(y)) or _.or_else(|x| Err(y)).

Why is this bad?

This can be written more concisely as _.map(|x| y) or _.map_err(|x| y).

Example

let _ = opt().and_then(|s| Some(s.len())); let _ = res().and_then(|s| if s.len() == 42 { Ok(10) } else { Ok(20) }); let _ = res().or_else(|s| if s.len() == 42 { Err(10) } else { Err(20) }); 

The correct use would be:

let _ = opt().map(|s| s.len()); let _ = res().map(|s| if s.len() == 42 { 10 } else { 20 }); let _ = res().map_err(|s| if s.len() == 42 { 10 } else { 20 }); 

Past names

• option_and_then_some

What it does

Checks for warn/deny/forbid attributes targeting the whole clippy::restriction category.

Why is this bad?

Restriction lints sometimes are in contrast with other lints or even go against idiomatic rust. These lints should only be enabled on a lint-by-lint basis and with careful consideration.

Example

#![deny(clippy::restriction)] 

Use instead:

#![deny(clippy::as_conversions)] 

What it does

Checks for if and match conditions that use blocks containing an expression, statements or conditions that use closures with blocks.

Why is this bad?

Style, using blocks in the condition makes it hard to read.

Examples

if { true } { /* ... */ } if { let x = somefunc(); x } { /* ... */ } match { let e = somefunc(); e } { // ... } 

Use instead:

if true { /* ... */ } let res = { let x = somefunc(); x }; if res { /* ... */ } let res = { let e = somefunc(); e }; match res { // ... } 

Past names

• block_in_if_condition_expr
• block_in_if_condition_stmt
• blocks_in_if_conditions

What it does

This lint warns about boolean comparisons in assert-like macros.

Why is this bad?

It is shorter to use the equivalent.

Example

assert_eq!("a".is_empty(), false); assert_ne!("a".is_empty(), true); 

Use instead:

assert!(!"a".is_empty()); 

What it does

Checks for expressions of the form x == true, x != true and order comparisons such as x < true (or vice versa) and suggest using the variable directly.

Why is this bad?

Unnecessary code.

Example

if x == true {} if y == false {} 

use x directly:

if x {} if !y {} 

What it does

Instead of using an if statement to convert a bool to an int, this lint suggests using a from() function or an as coercion.

Why is this bad?

Coercion or from() is another way to convert bool to a number. Both methods are guaranteed to return 1 for true, and 0 for false.

See https://doc.rust-lang.org/std/primitive.bool.html#impl-From%3Cbool%3E

Example

if condition { 1_i64 } else { 0 }; 

Use instead:

i64::from(condition); 

or

condition as i64; 

What it does

Checks for the usage of &expr as *const T or &mut expr as *mut T, and suggest using &raw const or &raw mut instead.

Why is this bad?

This would improve readability and avoid creating a reference that points to an uninitialized value or unaligned place. Read the &raw explanation in the Reference for more information.

Example

let val = 1; let p = &val as *const i32; let mut val_mut = 1; let p_mut = &mut val_mut as *mut i32; 

Use instead:

let val = 1; let p = &raw const val; let mut val_mut = 1; let p_mut = &raw mut val_mut; 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for &*(&T).

Why is this bad?

Dereferencing and then borrowing a reference value has no effect in most cases.

Known problems

False negative on such code:

let x = &12; let addr_x = &x as *const _ as usize; let addr_y = &&*x as *const _ as usize; // assert ok now, and lint triggered. // But if we fix it, assert will fail. assert_ne!(addr_x, addr_y); 

Example

let s = &String::new(); let a: &String = &* s; 

Use instead:

let a: &String = s; 

What it does

Checks for a borrow of a named constant with interior mutability.

Why is this bad?

Named constants are copied at every use site which means any change to their value will be lost after the newly created value is dropped. e.g.

use core::sync::atomic::{AtomicUsize, Ordering}; const ATOMIC: AtomicUsize = AtomicUsize::new(0); fn add_one() -> usize { // This will always return `0` since `ATOMIC` is copied before it's borrowed // for use by `fetch_add`. ATOMIC.fetch_add(1, Ordering::AcqRel) } 

Known problems

This lint does not, and cannot in general, determine if the borrow of the constant is used in a way which causes a mutation. e.g.

use core::cell::Cell; const CELL: Cell<usize> = Cell::new(0); fn get_cell() -> Cell<usize> { // This is fine. It borrows a copy of `CELL`, but never mutates it through the // borrow. CELL.clone() } 

There also exists types which contain private fields with interior mutability, but no way to both create a value as a constant and modify any mutable field using the type’s public interface (e.g. bytes::Bytes). As there is no reasonable way to scan a crate’s interface to see if this is the case, all such types will be linted. If this happens use the ignore-interior-mutability configuration option to allow the type.

Example

use std::sync::atomic::{AtomicUsize, Ordering::SeqCst}; const CONST_ATOM: AtomicUsize = AtomicUsize::new(12); CONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged assert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct 

Use instead:

use std::sync::atomic::{AtomicUsize, Ordering::SeqCst}; const CONST_ATOM: AtomicUsize = AtomicUsize::new(12); static STATIC_ATOM: AtomicUsize = CONST_ATOM; STATIC_ATOM.store(9, SeqCst); assert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance 

Configuration

• ignore-interior-mutability: A list of paths to types that should be treated as if they do not contain interior mutability

  (default: ["bytes::Bytes"])

What it does

Checks for usage of &Box<T> anywhere in the code. Check the Box documentation for more information.

Why is this bad?

A &Box<T> parameter requires the function caller to box T first before passing it to a function. Using &T defines a concrete type for the parameter and generalizes the function, this would also auto-deref to &T at the function call site if passed a &Box<T>.

Example

fn foo(bar: &Box<T>) { ... } 

Better:

fn foo(bar: &T) { ... } 

What it does

Checks for usage of Box<T> where T is a collection such as Vec anywhere in the code. Check the Box documentation for more information.

Why is this bad?

Collections already keeps their contents in a separate area on the heap. So if you Box them, you just add another level of indirection without any benefit whatsoever.

Example

struct X { values: Box<Vec<Foo>>, } 

Better:

struct X { values: Vec<Foo>, } 

Past names

• box_vec

Configuration

• avoid-breaking-exported-api: Suppress lints whenever the suggested change would cause breakage for other crates.

  (default: true)

What it does

checks for Box::new(Default::default()), which can be written as Box::default().

Why is this bad?

Box::default() is equivalent and more concise.

Example

let x: Box<String> = Box::new(Default::default()); 

Use instead:

let x: Box<String> = Box::default(); 

What it does

Checks for usage of Box<T> where an unboxed T would work fine.

Why is this bad?

This is an unnecessary allocation, and bad for performance. It is only necessary to allocate if you wish to move the box into something.

Example

fn foo(x: Box<u32>) {} 

Use instead:

fn foo(x: u32) {} 

Configuration

• too-large-for-stack: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap

  (default: 200)

What it does

Checks if the if and else block contain shared code that can be moved out of the blocks.

Why is this bad?

Duplicate code is less maintainable.

Example

let foo = if … { println!("Hello World"); 13 } else { println!("Hello World"); 42 }; 

Use instead:

println!("Hello World"); let foo = if … { 13 } else { 42 }; 

What it does

Warns if a generic shadows a built-in type.

Why is this bad?

This gives surprising type errors.

Example

impl<u32> Foo<u32> { fn impl_func(&self) -> u32 { 42 } } 

What it does

Checks for hard to read slices of byte characters, that could be more easily expressed as a byte string.

Why is this bad?

Potentially makes the string harder to read.

Example

&[b'H', b'e', b'l', b'l', b'o']; 

Use instead:

b"Hello" 

What it does

It checks for str::bytes().count() and suggests replacing it with str::len().

Why is this bad?

str::bytes().count() is longer and may not be as performant as using str::len().

Example

"hello".bytes().count(); String::from("hello").bytes().count(); 

Use instead:

"hello".len(); String::from("hello").len(); 

What it does

Checks for the use of .bytes().nth().

Why is this bad?

.as_bytes().get() is more efficient and more readable.

Example

"Hello".bytes().nth(3); 

Use instead:

"Hello".as_bytes().get(3); 

What it does

Checks to see if all common metadata is defined in Cargo.toml. See: https://rust-lang-nursery.github.io/api-guidelines/documentation.html#cargotoml-includes-all-common-metadata-c-metadata

Why is this bad?

It will be more difficult for users to discover the purpose of the crate, and key information related to it.

Example

[package] name = "clippy" version = "0.0.212" repository = "https://github.com/rust-lang/rust-clippy" readme = "README.md" license = "MIT OR Apache-2.0" keywords = ["clippy", "lint", "plugin"] categories = ["development-tools", "development-tools::cargo-plugins"] 

Should include a description field like:

[package] name = "clippy" version = "0.0.212" description = "A bunch of helpful lints to avoid common pitfalls in Rust" repository = "https://github.com/rust-lang/rust-clippy" readme = "README.md" license = "MIT OR Apache-2.0" keywords = ["clippy", "lint", "plugin"] categories = ["development-tools", "development-tools::cargo-plugins"] 

Configuration

• cargo-ignore-publish: For internal testing only, ignores the current publish settings in the Cargo manifest.

  (default: false)

What it does

Checks for calls to ends_with with possible file extensions and suggests to use a case-insensitive approach instead.

Why is this bad?

ends_with is case-sensitive and may not detect files with a valid extension.

Example

fn is_rust_file(filename: &str) -> bool { filename.ends_with(".rs") } 

Use instead:

fn is_rust_file(filename: &str) -> bool { let filename = std::path::Path::new(filename); filename.extension() .map_or(false, |ext| ext.eq_ignore_ascii_case("rs")) } 

What it does

Checks for usage of the abs() method that cast the result to unsigned.

Why is this bad?

The unsigned_abs() method avoids panic when called on the MIN value.

Example

let x: i32 = -42; let y: u32 = x.abs() as u32; 

Use instead:

let x: i32 = -42; let y: u32 = x.unsigned_abs(); 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for casts from an enum tuple constructor to an integer.

Why is this bad?

The cast is easily confused with casting a c-like enum value to an integer.

Example

enum E { X(i32) }; let _ = E::X as usize; 

What it does

Checks for casts from an enum type to an integral type that will definitely truncate the value.

Why is this bad?

The resulting integral value will not match the value of the variant it came from.

Example

enum E { X = 256 }; let _ = E::X as u8; 

What it does

Checks for casts between numeric types that can be replaced by safe conversion functions.

Why is this bad?

Rust’s as keyword will perform many kinds of conversions, including silently lossy conversions. Conversion functions such as i32::from will only perform lossless conversions. Using the conversion functions prevents conversions from becoming silently lossy if the input types ever change, and makes it clear for people reading the code that the conversion is lossless.

Example

fn as_u64(x: u8) -> u64 { x as u64 } 

Using ::from would look like this:

fn as_u64(x: u8) -> u64 { u64::from(x) } 

What it does

Checks for a known NaN float being cast to an integer

Why is this bad?

NaNs are cast into zero, so one could simply use this and make the code more readable. The lint could also hint at a programmer error.

Example

let _ = (0.0_f32 / 0.0) as u64; 

Use instead:

let _ = 0_u64; 

What it does

Checks for casts between numeric types that may truncate large values. This is expected behavior, so the cast is Allow by default. It suggests user either explicitly ignore the lint, or use try_from() and handle the truncation, default, or panic explicitly.

Why is this bad?

In some problem domains, it is good practice to avoid truncation. This lint can be activated to help assess where additional checks could be beneficial.

Example

fn as_u8(x: u64) -> u8 { x as u8 } 

Use instead:

fn as_u8(x: u64) -> u8 { if let Ok(x) = u8::try_from(x) { x } else { todo!(); } } // Or #[allow(clippy::cast_possible_truncation)] fn as_u16(x: u64) -> u16 { x as u16 } 

What it does

Checks for casts from an unsigned type to a signed type of the same size, or possibly smaller due to target-dependent integers. Performing such a cast is a no-op for the compiler (that is, nothing is changed at the bit level), and the binary representation of the value is reinterpreted. This can cause wrapping if the value is too big for the target signed type. However, the cast works as defined, so this lint is Allow by default.

Why is this bad?

While such a cast is not bad in itself, the results can be surprising when this is not the intended behavior:

Example

let _ = u32::MAX as i32; // will yield a value of `-1` 

Use instead:

let _ = i32::try_from(u32::MAX).ok(); 

What it does

Checks for casts from any numeric type to a float type where the receiving type cannot store all values from the original type without rounding errors. This possible rounding is to be expected, so this lint is Allow by default.

Basically, this warns on casting any integer with 32 or more bits to f32 or any 64-bit integer to f64.

Why is this bad?

It’s not bad at all. But in some applications it can be helpful to know where precision loss can take place. This lint can help find those places in the code.

Example

let x = u64::MAX; x as f64; 

What it does

Checks for casts, using as or pointer::cast, from a less strictly aligned pointer to a more strictly aligned pointer.

Why is this bad?

Dereferencing the resulting pointer may be undefined behavior.

Known problems

Using std::ptr::read_unaligned and std::ptr::write_unaligned or similar on the resulting pointer is fine. Is over-zealous: casts with manual alignment checks or casts like u64 -> u8 -> u16 can be fine. Miri is able to do a more in-depth analysis.

Example

let _ = (&1u8 as *const u8) as *const u16; let _ = (&mut 1u8 as *mut u8) as *mut u16; (&1u8 as *const u8).cast::<u16>(); (&mut 1u8 as *mut u8).cast::<u16>(); 

What it does

Checks for casts from a signed to an unsigned numeric type. In this case, negative values wrap around to large positive values, which can be quite surprising in practice. However, since the cast works as defined, this lint is Allow by default.

Why is this bad?

Possibly surprising results. You can activate this lint as a one-time check to see where numeric wrapping can arise.

Example

let y: i8 = -1; y as u64; // will return 18446744073709551615 

What it does

Checks for as casts between raw pointers to slices with differently sized elements.

Why is this bad?

The produced raw pointer to a slice does not update its length metadata. The produced pointer will point to a different number of bytes than the original pointer because the length metadata of a raw slice pointer is in elements rather than bytes. Producing a slice reference from the raw pointer will either create a slice with less data (which can be surprising) or create a slice with more data and cause Undefined Behavior.

Example

// Missing data

let a = [1_i32, 2, 3, 4]; let p = &a as *const [i32] as *const [u8]; unsafe { println!("{:?}", &*p); } 

// Undefined Behavior (note: also potential alignment issues)

let a = [1_u8, 2, 3, 4]; let p = &a as *const [u8] as *const [u32]; unsafe { println!("{:?}", &*p); } 

Instead use ptr::slice_from_raw_parts to construct a slice from a data pointer and the correct length

let a = [1_i32, 2, 3, 4]; let old_ptr = &a as *const [i32]; // The data pointer is cast to a pointer to the target `u8` not `[u8]` // The length comes from the known length of 4 i32s times the 4 bytes per i32 let new_ptr = core::ptr::slice_from_raw_parts(old_ptr as *const u8, 16); unsafe { println!("{:?}", &*new_ptr); } 

What it does

Checks for a raw slice being cast to a slice pointer

Why is this bad?

This can result in multiple &mut references to the same location when only a pointer is required. ptr::slice_from_raw_parts is a safe alternative that doesn’t require the same safety requirements to be upheld.

Example

let _: *const [u8] = std::slice::from_raw_parts(ptr, len) as *const _; let _: *mut [u8] = std::slice::from_raw_parts_mut(ptr, len) as *mut _; 

Use instead:

let _: *const [u8] = std::ptr::slice_from_raw_parts(ptr, len); let _: *mut [u8] = std::ptr::slice_from_raw_parts_mut(ptr, len); 

What it does

Checks for usage of cfg that excludes code from test builds. (i.e., #[cfg(not(test))])

Why is this bad?

This may give the false impression that a codebase has 100% coverage, yet actually has untested code. Enabling this also guards against excessive mockery as well, which is an anti-pattern.

Example

#[cfg(not(test))] important_check(); // I'm not actually tested, but not including me will falsely increase coverage! 

Use instead:

important_check(); 

What it does

Checks for usage of a character position yielded by .chars().enumerate() in a context where a byte index is expected, such as an argument to a specific str method or indexing into a str or String.

Why is this bad?

A character (more specifically, a Unicode scalar value) that is yielded by str::chars can take up multiple bytes, so a character position does not necessarily have the same byte index at which the character is stored. Thus, using the character position where a byte index is expected can unexpectedly return wrong values or panic when the string consists of multibyte characters.

For example, the character a in äa is stored at byte index 2 but has the character position 1. Using the character position 1 to index into the string will lead to a panic as it is in the middle of the first character.

Instead of .chars().enumerate(), the correct iterator to use is .char_indices(), which yields byte indices.

This pattern is technically fine if the strings are known to only use the ASCII subset, though in those cases it would be better to use bytes() directly to make the intent clearer, but there is also no downside to just using .char_indices() directly and supporting non-ASCII strings.

You may also want to read the chapter on strings in the Rust Book which goes into this in more detail.

Example

for (idx, c) in s.chars().enumerate() { let _ = s[idx..]; // ⚠️ Panics for strings consisting of multibyte characters } 

Use instead:

for (idx, c) in s.char_indices() { let _ = s[idx..]; } 

What it does

Checks for expressions where a character literal is cast to u8 and suggests using a byte literal instead.

Why is this bad?

In general, casting values to smaller types is error-prone and should be avoided where possible. In the particular case of converting a character literal to u8, it is easy to avoid by just using a byte literal instead. As an added bonus, b'a' is also slightly shorter than 'a' as u8.

Example

'x' as u8 

A better version, using the byte literal:

b'x' 

What it does

Checks for usage of _.chars().last() or _.chars().next_back() on a str to check if it ends with a given char.

Why is this bad?

Readability, this can be written more concisely as _.ends_with(_).

Example

name.chars().last() == Some('_') || name.chars().next_back() == Some('-'); 

Use instead:

name.ends_with('_') || name.ends_with('-'); 

What it does

Checks for usage of .chars().next() on a str to check if it starts with a given char.

Why is this bad?

Readability, this can be written more concisely as _.starts_with(_).

Example

let name = "foo"; if name.chars().next() == Some('_') {}; 

Use instead:

let name = "foo"; if name.starts_with('_') {}; 

What it does

Checks for explicit bounds checking when casting.

Why is this bad?

Reduces the readability of statements & is error prone.

Example

foo <= i32::MAX as u32; 

Use instead:

i32::try_from(foo).is_ok(); 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for usage of .drain(..) for the sole purpose of clearing a container.

Why is this bad?

This creates an unnecessary iterator that is dropped immediately.

Calling .clear() also makes the intent clearer.

Example

let mut v = vec![1, 2, 3]; v.drain(..); 

Use instead:

let mut v = vec![1, 2, 3]; v.clear(); 

What it does

Checks for usage of .clone() on a Copy type.

Why is this bad?

The only reason Copy types implement Clone is for generics, not for using the clone method on a concrete type.

Example

42u64.clone(); 

What it does

Checks for usage of .clone() on a ref-counted pointer, (Rc, Arc, rc::Weak, or sync::Weak), and suggests calling Clone via unified function syntax instead (e.g., Rc::clone(foo)).

Why restrict this?

Calling .clone() on an Rc, Arc, or Weak can obscure the fact that only the pointer is being cloned, not the underlying data.

Example

let x = Rc::new(1); x.clone(); 

Use instead:

Rc::clone(&x); 

What it does

Checks for usage of cloned() on an Iterator or Option where copied() could be used instead.

Why is this bad?

copied() is better because it guarantees that the type being cloned implements Copy.

Example

[1, 2, 3].iter().cloned(); 

Use instead:

[1, 2, 3].iter().copied(); 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

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)); 

What it does

This lint checks for equality comparisons with ptr::null

Why is this bad?

It’s easier and more readable to use the inherent .is_null() method instead

Example

use std::ptr; if x == ptr::null { // .. } 

Use instead:

if x.is_null() { // .. } 

What it does

Checks for conversions to owned values just for the sake of a comparison.

Why is this bad?

The comparison can operate on a reference, so creating an owned value effectively throws it away directly afterwards, which is needlessly consuming code and heap space.

Example

if x.to_owned() == y {} 

Use instead:

if x == y {} 

What it does

Protects against unintended coercion of references to container types to &dyn Any when the container type dereferences to a dyn Any which could be directly referenced instead.

Why is this bad?

The intention is usually to get a reference to the dyn Any the value dereferences to, rather than coercing a reference to the container itself to &dyn Any.

Example

Because Box<dyn Any> itself implements Any, &Box<dyn Any> can be coerced to an &dyn Any which refers to the Box itself, rather than the inner dyn Any.

let x: Box<dyn Any> = Box::new(0u32); let dyn_any_of_box: &dyn Any = &x; // Fails as we have a &dyn Any to the Box, not the u32 assert_eq!(dyn_any_of_box.downcast_ref::<u32>(), None); 

Use instead:

let x: Box<dyn Any> = Box::new(0u32); let dyn_any_of_u32: &dyn Any = &*x; // Succeeds since we have a &dyn Any to the inner u32! assert_eq!(dyn_any_of_u32.downcast_ref::<u32>(), Some(&0u32)); 

What it does

We used to think it measured how hard a method is to understand.

Why is this bad?

Ideally, we would like to be able to measure how hard a function is to understand given its context (what we call its Cognitive Complexity). But that’s not what this lint does. See “Known problems”

Known problems

The true Cognitive Complexity of a method is not something we can calculate using modern technology. This lint has been left in restriction so as to not mislead users into using this lint as a measurement tool.

For more detailed information, see rust-clippy#3793

Lints to consider instead of this

• excessive_nesting
• too_many_lines

Past names

• cyclomatic_complexity

Configuration

• cognitive-complexity-threshold: The maximum cognitive complexity a function can have

  (default: 25)

What it does

Checks for collapsible else { if ... } expressions that can be collapsed to else if ....

Why is this bad?

Each if-statement adds one level of nesting, which makes code look more complex than it really is.

Example

 if x { … } else { if y { … } } 

Should be written:

if x { … } else if y { … } 

Configuration

• lint-commented-code: Whether collapsible if and else if chains are linted if they contain comments inside the parts that would be collapsed.

  (default: false)

What it does

Checks for nested if statements which can be collapsed by &&-combining their conditions.

Why is this bad?

Each if-statement adds one level of nesting, which makes code look more complex than it really is.

Example

if x { if y { // … } } 

Use instead:

if x && y { // … } 

Configuration

• lint-commented-code: Whether collapsible if and else if chains are linted if they contain comments inside the parts that would be collapsed.

  (default: false)

What it does

Finds nested match or if let expressions where the patterns may be “collapsed” together without adding any branches.

Note that this lint is not intended to find all cases where nested match patterns can be merged, but only cases where merging would most likely make the code more readable.

Why is this bad?

It is unnecessarily verbose and complex.

Example

fn func(opt: Option<Result<u64, String>>) { let n = match opt { Some(n) => match n { Ok(n) => n, _ => return, } None => return, }; } 

Use instead:

fn func(opt: Option<Result<u64, String>>) { let n = match opt { Some(Ok(n)) => n, _ => return, }; } 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for consecutive calls to str::replace (2 or more) that can be collapsed into a single call.

Why is this bad?

Consecutive str::replace calls scan the string multiple times with repetitive code.

Example

let hello = "hesuo worpd" .replace('s', "l") .replace("u", "l") .replace('p', "l"); 

Use instead:

let hello = "hesuo worpd".replace(['s', 'u', 'p'], "l"); 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for collections that are never queried.

Why is this bad?

Putting effort into constructing a collection but then never querying it might indicate that the author forgot to do whatever they intended to do with the collection. Example: Clone a vector, sort it for iteration, but then mistakenly iterate the original vector instead.

Example

let mut sorted_samples = samples.clone(); sorted_samples.sort(); for sample in &samples { // Oops, meant to use `sorted_samples`. println!("{sample}"); } 

Use instead:

let mut sorted_samples = samples.clone(); sorted_samples.sort(); for sample in &sorted_samples { println!("{sample}"); } 

What it does

Checks comparison chains written with if that can be rewritten with match and cmp.

Why is this bad?

if is not guaranteed to be exhaustive and conditionals can get repetitive

Known problems

The match statement may be slower due to the compiler not inlining the call to cmp. See issue #5354

Example

fn f(x: u8, y: u8) { if x > y { a() } else if x < y { b() } else { c() } } 

Use instead:

use std::cmp::Ordering; fn f(x: u8, y: u8) { match x.cmp(&y) { Ordering::Greater => a(), Ordering::Less => b(), Ordering::Equal => c() } } 

What it does

Checks for comparing to an empty slice such as "" or [], and suggests using .is_empty() where applicable.

Why is this bad?

Some structures can answer .is_empty() much faster than checking for equality. So it is good to get into the habit of using .is_empty(), and having it is cheap. Besides, it makes the intent clearer than a manual comparison in some contexts.

Example

if s == "" { .. } if arr == [] { .. } 

Use instead:

if s.is_empty() { .. } if arr.is_empty() { .. } 

What it does

Checks for casts of a primitive method pointer like max/min to any integer type.

Why restrict this?

Casting a function pointer to an integer can have surprising results and can occur accidentally if parentheses are omitted from a function call. If you aren’t doing anything low-level with function pointers then you can opt out of casting functions to integers in order to avoid mistakes. Alternatively, you can use this lint to audit all uses of function pointer casts in your code.

Example

let _ = u16::max as usize; 

Use instead:

let _ = u16::MAX as usize; 

What it does

It identifies calls to .is_empty() on constant values.

Why is this bad?

String literals and constant values are known at compile time. Checking if they are empty will always return the same value. This might not be the intention of the expression.

Example

let value = ""; if value.is_empty() { println!("the string is empty"); } 

Use instead:

println!("the string is empty"); 

What it does

Checks for types that implement Copy as well as Iterator.

Why is this bad?

Implicit copies can be confusing when working with iterator combinators.

Example

#[derive(Copy, Clone)] struct Countdown(u8); impl Iterator for Countdown { // ... } let a: Vec<_> = my_iterator.take(1).collect(); let b: Vec<_> = my_iterator.collect(); 

What it does

Checks for usage of crate as opposed to $crate in a macro definition.

Why is this bad?

crate refers to the macro call’s crate, whereas $crate refers to the macro definition’s crate. Rarely is the former intended. See: https://doc.rust-lang.org/reference/macros-by-example.html#hygiene

Example

#[macro_export] macro_rules! print_message { () => { println!("{}", crate::MESSAGE); }; } pub const MESSAGE: &str = "Hello!"; 

Use instead:

#[macro_export] macro_rules! print_message { () => { println!("{}", $crate::MESSAGE); }; } pub const MESSAGE: &str = "Hello!"; 

Note that if the use of crate is intentional, an allow attribute can be applied to the macro definition, e.g.:

#[allow(clippy::crate_in_macro_def)] macro_rules! ok { ... crate::foo ... } 

What it does

Checks usage of std::fs::create_dir and suggest using std::fs::create_dir_all instead.

Why restrict this?

Sometimes std::fs::create_dir is mistakenly chosen over std::fs::create_dir_all, resulting in failure when more than one directory needs to be created or when the directory already exists. Crates which never need to specifically create a single directory may wish to prevent this mistake.

Example

std::fs::create_dir("foo"); 

Use instead:

std::fs::create_dir_all("foo"); 

What it does

Checks for transmutes between a type T and *T.

Why is this bad?

It’s easy to mistakenly transmute between a type and a pointer to that type.

Example

core::intrinsics::transmute(t) // where the result type is the same as // `*t` or `&t`'s 

What it does

Checks for usage of the dbg! macro.

Why restrict this?

The dbg! macro is intended as a debugging tool. It should not be present in released software or committed to a version control system.

Example

dbg!(true) 

Use instead:

true 

Configuration

• allow-dbg-in-tests: Whether dbg! should be allowed in test functions or #[cfg(test)]

  (default: false)

What it does

Checks for function/method calls with a mutable parameter in debug_assert!, debug_assert_eq! and debug_assert_ne! macros.

Why is this bad?

In release builds debug_assert! macros are optimized out by the compiler. Therefore mutating something in a debug_assert! macro results in different behavior between a release and debug build.

Example

debug_assert_eq!(vec![3].pop(), Some(3)); // or debug_assert!(takes_a_mut_parameter(&mut x)); 

What it does

Warns if there is a better representation for a numeric literal.

Why restrict this?

Especially for big powers of 2, a hexadecimal representation is usually more readable than a decimal representation.

Example

`255` => `0xFF` `65_535` => `0xFFFF` `4_042_322_160` => `0xF0F0_F0F0` 

Configuration

• literal-representation-threshold: The lower bound for linting decimal literals

  (default: 16384)

What it does

Checks for the declaration of named constant which contain interior mutability.

Why is this bad?

Named constants are copied at every use site which means any change to their value will be lost after the newly created value is dropped. e.g.

use core::sync::atomic::{AtomicUsize, Ordering}; const ATOMIC: AtomicUsize = AtomicUsize::new(0); fn add_one() -> usize { // This will always return `0` since `ATOMIC` is copied before it's used. ATOMIC.fetch_add(1, Ordering::AcqRel) } 

If shared modification of the value is desired, a static item is needed instead. If that is not desired, a const fn constructor should be used to make it obvious at the use site that a new value is created.

Known problems

Prior to const fn stabilization this was the only way to provide a value which could initialize a static item (e.g. the std::sync::ONCE_INIT constant). In this case the use of const is required and this lint should be suppressed.

There also exists types which contain private fields with interior mutability, but no way to both create a value as a constant and modify any mutable field using the type’s public interface (e.g. bytes::Bytes). As there is no reasonable way to scan a crate’s interface to see if this is the case, all such types will be linted. If this happens use the ignore-interior-mutability configuration option to allow the type.

Example

use std::sync::atomic::{AtomicUsize, Ordering::SeqCst}; const CONST_ATOM: AtomicUsize = AtomicUsize::new(12); CONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged assert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct 

Use instead:

static STATIC_ATOM: AtomicUsize = AtomicUsize::new(15); STATIC_ATOM.store(9, SeqCst); assert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance 

Configuration

• ignore-interior-mutability: A list of paths to types that should be treated as if they do not contain interior mutability

  (default: ["bytes::Bytes"])

What it does

Checks for construction on unit struct using default.

Why is this bad?

This adds code complexity and an unnecessary function call.

Example

#[derive(Default)] struct S<T> { _marker: PhantomData<T> } let _: S<i32> = S { _marker: PhantomData::default() }; 

Use instead:

struct S<T> { _marker: PhantomData<T> } let _: S<i32> = S { _marker: PhantomData }; 

What it does

It checks for std::iter::Empty::default() and suggests replacing it with std::iter::empty().

Why is this bad?

std::iter::empty() is the more idiomatic way.

Example

let _ = std::iter::Empty::<usize>::default(); let iter: std::iter::Empty<usize> = std::iter::Empty::default(); 

Use instead:

let _ = std::iter::empty::<usize>(); let iter: std::iter::Empty<usize> = std::iter::empty(); 

What it does

Checks for usage of unconstrained numeric literals which may cause default numeric fallback in type inference.

Default numeric fallback means that if numeric types have not yet been bound to concrete types at the end of type inference, then integer type is bound to i32, and similarly floating type is bound to f64.

See RFC0212 for more information about the fallback.

Why restrict this?

To ensure that every numeric type is chosen explicitly rather than implicitly.

Known problems

This lint is implemented using a custom algorithm independent of rustc’s inference, which results in many false positives and false negatives.

Example

let i = 10; let f = 1.23; 

Use instead:

let i = 10_i32; let f = 1.23_f64; 

What it does

Checks for literal calls to Default::default().

Why is this bad?

It’s easier for the reader if the name of the type is used, rather than the generic Default.

Example

let s: String = Default::default(); 

Use instead:

let s = String::default(); 

What it does

Displays a warning when a union is declared with the default representation (without a #[repr(C)] attribute).

Why restrict this?

Unions in Rust have unspecified layout by default, despite many people thinking that they lay out each field at the start of the union (like C does). That is, there are no guarantees about the offset of the fields for unions with multiple non-ZST fields without an explicitly specified layout. These cases may lead to undefined behavior in unsafe blocks.

Example

union Foo { a: i32, b: u32, } fn main() { let _x: u32 = unsafe { Foo { a: 0_i32 }.b // Undefined behavior: `b` is allowed to be padding }; } 

Use instead:

#[repr(C)] union Foo { a: i32, b: u32, } fn main() { let _x: u32 = unsafe { Foo { a: 0_i32 }.b // Now defined behavior, this is just an i32 -> u32 transmute }; } 

What it does

Checks for #[cfg_attr(rustfmt, rustfmt_skip)] and suggests to replace it with #[rustfmt::skip].

Why is this bad?

Since tool_attributes (rust-lang/rust#44690) are stable now, they should be used instead of the old cfg_attr(rustfmt) attributes.

Known problems

This lint doesn’t detect crate level inner attributes, because they get processed before the PreExpansionPass lints get executed. See #3123

Example

#[cfg_attr(rustfmt, rustfmt_skip)] fn main() { } 

Use instead:

#[rustfmt::skip] fn main() { } 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for #[cfg_attr(feature = "cargo-clippy", ...)] and for #[cfg(feature = "cargo-clippy")] and suggests to replace it with #[cfg_attr(clippy, ...)] or #[cfg(clippy)].

Why is this bad?

This feature has been deprecated for years and shouldn’t be used anymore.

Example

#[cfg(feature = "cargo-clippy")] struct Bar; 

Use instead:

#[cfg(clippy)] struct Bar; 

What it does

Checks for #[deprecated] annotations with a since field that is not a valid semantic version. Also allows “TBD” to signal future deprecation.

Why is this bad?

For checking the version of the deprecation, it must be a valid semver. Failing that, the contained information is useless.

Example

#[deprecated(since = "forever")] fn something_else() { /* ... */ } 

What it does

Checks for usage of *& and *&mut in expressions.

Why is this bad?

Immediately dereferencing a reference is no-op and makes the code less clear.

Known problems

Multiple dereference/addrof pairs are not handled so the suggested fix for x = **&&y is x = *&y, which is still incorrect.

Example

let a = f(*&mut b); let c = *&d; 

Use instead:

let a = f(b); let c = d; 

What it does

Checks for slicing expressions which are equivalent to dereferencing the value.

Why restrict this?

Some people may prefer to dereference rather than slice.

Example

let vec = vec![1, 2, 3]; let slice = &vec[..]; 

Use instead:

let vec = vec![1, 2, 3]; let slice = &*vec; 

What it does

Detects manual std::default::Default implementations that are identical to a derived implementation.

Why is this bad?

It is less concise.

Example

struct Foo { bar: bool } impl Default for Foo { fn default() -> Self { Self { bar: false } } } 

Use instead:

#[derive(Default)] struct Foo { bar: bool } 

Known problems

Derive macros sometimes use incorrect bounds in generic types and the user defined impl may be more generalized or specialized than what derive will produce. This lint can’t detect the manual impl has exactly equal bounds, and therefore this lint is disabled for types with generic parameters.

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Lints against manual PartialOrd and Ord implementations for types with a derived Ord or PartialOrd implementation.

Why is this bad?

The implementation of these traits must agree (for example for use with sort) so it’s probably a bad idea to use a default-generated Ord implementation with an explicitly defined PartialOrd. In particular, the following must hold for any type implementing Ord:

k1.cmp(&k2) == k1.partial_cmp(&k2).unwrap() 

Example

#[derive(Ord, PartialEq, Eq)] struct Foo; impl PartialOrd for Foo { ... } 

Use instead:

#[derive(PartialEq, Eq)] struct Foo; impl PartialOrd for Foo { fn partial_cmp(&self, other: &Foo) -> Option<Ordering> { Some(self.cmp(other)) } } impl Ord for Foo { ... } 

or, if you don’t need a custom ordering:

#[derive(Ord, PartialOrd, PartialEq, Eq)] struct Foo; 

What it does

Checks for types that derive PartialEq and could implement Eq.

Why is this bad?

If a type T derives PartialEq and all of its members implement Eq, then T can always implement Eq. Implementing Eq allows T to be used in APIs that require Eq types. It also allows structs containing T to derive Eq themselves.

Example

#[derive(PartialEq)] struct Foo { i_am_eq: i32, i_am_eq_too: Vec<String>, } 

Use instead:

#[derive(PartialEq, Eq)] struct Foo { i_am_eq: i32, i_am_eq_too: Vec<String>, } 

What it does

Lints against manual PartialEq implementations for types with a derived Hash implementation.

Why is this bad?

The implementation of these traits must agree (for example for use with HashMap) so it’s probably a bad idea to use a default-generated Hash implementation with an explicitly defined PartialEq. In particular, the following must hold for any type:

k1 == k2 ⇒ hash(k1) == hash(k2) 

Example

#[derive(Hash)] struct Foo; impl PartialEq for Foo { ... } 

Past names

• derive_hash_xor_eq

What it does

Denies the configured macros in clippy.toml

Note: Even though this lint is warn-by-default, it will only trigger if macros are defined in the clippy.toml file.

Why is this bad?

Some macros are undesirable in certain contexts, and it’s beneficial to lint for them as needed.

Example

An example clippy.toml configuration:

disallowed-macros = [ # Can use a string as the path of the disallowed macro. "std::print", # Can also use an inline table with a `path` key. { path = "std::println" }, # When using an inline table, can add a `reason` for why the macro # is disallowed. { path = "serde::Serialize", reason = "no serializing" }, # This would normally error if the path is incorrect, but with `allow-invalid` = `true`, # it will be silently ignored { path = "std::invalid_macro", reason = "use alternative instead", allow-invalid = true } ] 

use serde::Serialize; println!("warns"); // The diagnostic will contain the message "no serializing" #[derive(Serialize)] struct Data { name: String, value: usize, } 

Configuration

• disallowed-macros: The list of disallowed macros, written as fully qualified paths.

Fields:

• path (required): the fully qualified path to the macro that should be disallowed

• reason (optional): explanation why this macro is disallowed

• replacement (optional): suggested alternative macro

• allow-invalid (optional, false by default): when set to true, it will ignore this entry if the path doesn’t exist, instead of emitting an error

  (default: [])

What it does

Denies the configured methods and functions in clippy.toml

Note: Even though this lint is warn-by-default, it will only trigger if methods are defined in the clippy.toml file.

Why is this bad?

Some methods are undesirable in certain contexts, and it’s beneficial to lint for them as needed.

Example

An example clippy.toml configuration:

disallowed-methods = [ # Can use a string as the path of the disallowed method. "std::boxed::Box::new", # Can also use an inline table with a `path` key. { path = "std::time::Instant::now" }, # When using an inline table, can add a `reason` for why the method # is disallowed. { path = "std::vec::Vec::leak", reason = "no leaking memory" }, # Can also add a `replacement` that will be offered as a suggestion. { path = "std::sync::Mutex::new", reason = "prefer faster & simpler non-poisonable mutex", replacement = "parking_lot::Mutex::new" }, # This would normally error if the path is incorrect, but with `allow-invalid` = `true`, # it will be silently ignored { path = "std::fs::InvalidPath", reason = "use alternative instead", allow-invalid = true }, ] 

let xs = vec![1, 2, 3, 4]; xs.leak(); // Vec::leak is disallowed in the config. // The diagnostic contains the message "no leaking memory". let _now = Instant::now(); // Instant::now is disallowed in the config. let _box = Box::new(3); // Box::new is disallowed in the config. 

Use instead:

let mut xs = Vec::new(); // Vec::new is _not_ disallowed in the config. xs.push(123); // Vec::push is _not_ disallowed in the config. 

Past names

• disallowed_method

Configuration

• disallowed-methods: The list of disallowed methods, written as fully qualified paths.

Fields:

• path (required): the fully qualified path to the method that should be disallowed

• reason (optional): explanation why this method is disallowed

• replacement (optional): suggested alternative method

• allow-invalid (optional, false by default): when set to true, it will ignore this entry if the path doesn’t exist, instead of emitting an error

  (default: [])

What it does

Checks for usage of disallowed names for variables, such as foo.

Why is this bad?

These names are usually placeholder names and should be avoided.

Example

let foo = 3.14; 

Past names

• blacklisted_name

Configuration

• disallowed-names: The list of disallowed names to lint about. NB: bar is not here since it has legitimate uses. The value ".." can be used as part of the list to indicate that the configured values should be appended to the default configuration of Clippy. By default, any configuration will replace the default value.

  (default: ["foo", "baz", "quux"])

What it does

Checks for usage of unicode scripts other than those explicitly allowed by the lint config.

This lint doesn’t take into account non-text scripts such as Unknown and Linear_A. It also ignores the Common script type. While configuring, be sure to use official script name aliases from the list of supported scripts.

See also: non_ascii_idents.

Why restrict this?

It may be not desired to have many different scripts for identifiers in the codebase.

Note that if you only want to allow typical English, you might want to use built-in non_ascii_idents lint instead.

Example

// Assuming that `clippy.toml` contains the following line: // allowed-scripts = ["Latin", "Cyrillic"] let counter = 10; // OK, latin is allowed. let счётчик = 10; // OK, cyrillic is allowed. let zähler = 10; // OK, it's still latin. let カウンタ = 10; // Will spawn the lint. 

Configuration

• allowed-scripts: The list of unicode scripts allowed to be used in the scope.

  (default: ["Latin"])

What it does

Denies the configured types in clippy.toml.

Note: Even though this lint is warn-by-default, it will only trigger if types are defined in the clippy.toml file.

Why is this bad?

Some types are undesirable in certain contexts.

Example:

An example clippy.toml configuration:

disallowed-types = [ # Can use a string as the path of the disallowed type. "std::collections::BTreeMap", # Can also use an inline table with a `path` key. { path = "std::net::TcpListener" }, # When using an inline table, can add a `reason` for why the type # is disallowed. { path = "std::net::Ipv4Addr", reason = "no IPv4 allowed" }, # Can also add a `replacement` that will be offered as a suggestion. { path = "std::sync::Mutex", reason = "prefer faster & simpler non-poisonable mutex", replacement = "parking_lot::Mutex" }, # This would normally error if the path is incorrect, but with `allow-invalid` = `true`, # it will be silently ignored { path = "std::invalid::Type", reason = "use alternative instead", allow-invalid = true } ] 

use std::collections::BTreeMap; // or its use let x = std::collections::BTreeMap::new(); 

Use instead:

// A similar type that is allowed by the config use std::collections::HashMap; 

Past names

• disallowed_type

Configuration

• disallowed-types: The list of disallowed types, written as fully qualified paths.

Fields:

• path (required): the fully qualified path to the type that should be disallowed

• reason (optional): explanation why this type is disallowed

• replacement (optional): suggested alternative type

• allow-invalid (optional, false by default): when set to true, it will ignore this entry if the path doesn’t exist, instead of emitting an error

  (default: [])

What it does

Checks for diverging calls that are not match arms or statements.

Why is this bad?

It is often confusing to read. In addition, the sub-expression evaluation order for Rust is not well documented.

Known problems

Someone might want to use some_bool || panic!() as a shorthand.

Example

let a = b() || panic!() || c(); // `c()` is dead, `panic!()` is only called if `b()` returns `false` let x = (a, b, c, panic!()); // can simply be replaced by `panic!()` 

What it does

Checks the doc comments have unbroken links, mostly caused by bad formatted links such as broken across multiple lines.

Why is this bad?

Because documentation generated by rustdoc will be broken since expected links won’t be links and just text.

Examples

This link is broken:

/// [example of a bad link](https:// /// github.com/rust-lang/rust-clippy/) pub fn do_something() {} 

It shouldn’t be broken across multiple lines to work:

/// [example of a good link](https://github.com/rust-lang/rust-clippy/) pub fn do_something() {} 

What it does

Detects doc comment linebreaks that use double spaces to separate lines, instead of back-slash (\).

Why is this bad?

Double spaces, when used as doc comment linebreaks, can be difficult to see, and may accidentally be removed during automatic formatting or manual refactoring. The use of a back-slash (\) is clearer in this regard.

Example

The two replacement dots in this example represent a double space.

/// This command takes two numbers as inputs and·· /// adds them together, and then returns the result. fn add(l: i32, r: i32) -> i32 { l + r } 

Use instead:

/// This command takes two numbers as inputs and\ /// adds them together, and then returns the result. fn add(l: i32, r: i32) -> i32 { l + r } 

What it does

Checks if included files in doc comments are included only for cfg(doc).

Why restrict this?

These files are not useful for compilation but will still be included. Also, if any of these non-source code file is updated, it will trigger a recompilation.

Known problems

Excluding this will currently result in the file being left out if the item’s docs are inlined from another crate. This may be fixed in a future version of rustdoc.

Example

#![doc = include_str!("some_file.md")] 

Use instead:

#![cfg_attr(doc, doc = include_str!("some_file.md"))] 

What it does

In CommonMark Markdown, the language used to write doc comments, a paragraph nested within a list or block quote does not need any line after the first one to be indented or marked. The specification calls this a “lazy paragraph continuation.”

Why is this bad?

This is easy to write but hard to read. Lazy continuations makes unintended markers hard to see, and make it harder to deduce the document’s intended structure.

Example

This table is probably intended to have two rows, but it does not. It has zero rows, and is followed by a block quote.

/// Range | Description /// ----- | ----------- /// >= 1 | fully opaque /// < 1 | partially see-through fn set_opacity(opacity: f32) {} 

Fix it by escaping the marker:

/// Range | Description /// ----- | ----------- /// \>= 1 | fully opaque /// < 1 | partially see-through fn set_opacity(opacity: f32) {} 

This example is actually intended to be a list:

/// * Do nothing. /// * Then do something. Whatever it is needs done, /// it should be done right now. 

Fix it by indenting the list contents:

/// * Do nothing. /// * Then do something. Whatever it is needs done, /// it should be done right now. 

What it does

Checks for links with code directly adjacent to code text: [`MyItem`]`<`[`u32`]`>`.

Why is this bad?

It can be written more simply using HTML-style <code> tags.

Example

//! [`first`](x)`second` 

Use instead:

//! <code>[first](x)second</code> 

What it does

Detects the syntax ['foo'] in documentation comments (notice quotes instead of backticks) outside of code blocks

Why is this bad?

It is likely a typo when defining an intra-doc link

Example

/// See also: ['foo'] fn bar() {} 

Use instead:

/// See also: [`foo`] fn bar() {} 

What it does

Checks for the presence of _, :: or camel-case words outside ticks in documentation.

Why is this bad?

Rustdoc supports markdown formatting, _, :: and camel-case probably indicates some code which should be included between ticks. _ can also be used for emphasis in markdown, this lint tries to consider that.

Known problems

Lots of bad docs won’t be fixed, what the lint checks for is limited, and there are still false positives. HTML elements and their content are not linted.

In addition, when writing documentation comments, including [] brackets inside a link text would trip the parser. Therefore, documenting link with [SmallVec<[T; INLINE_CAPACITY]>] and then [SmallVec<[T; INLINE_CAPACITY]>]: SmallVec would fail.

Examples

/// Do something with the foo_bar parameter. See also /// that::other::module::foo. // ^ `foo_bar` and `that::other::module::foo` should be ticked. fn doit(foo_bar: usize) {} 

// Link text with `[]` brackets should be written as following: /// Consume the array and return the inner /// [`SmallVec<[T; INLINE_CAPACITY]>`][SmallVec]. /// [SmallVec]: SmallVec fn main() {} 

Configuration

• doc-valid-idents: The list of words this lint should not consider as identifiers needing ticks. The value ".." can be used as part of the list to indicate, that the configured values should be appended to the default configuration of Clippy. By default, any configuration will replace the default value. For example:

• doc-valid-idents = ["ClipPy"] would replace the default list with ["ClipPy"].

• doc-valid-idents = ["ClipPy", ".."] would append ClipPy to the default list.

  (default: ["KiB", "MiB", "GiB", "TiB", "PiB", "EiB", "MHz", "GHz", "THz", "AccessKit", "CoAP", "CoreFoundation", "CoreGraphics", "CoreText", "DevOps", "Direct2D", "Direct3D", "DirectWrite", "DirectX", "ECMAScript", "GPLv2", "GPLv3", "GitHub", "GitLab", "IPv4", "IPv6", "InfiniBand", "RoCE", "ClojureScript", "CoffeeScript", "JavaScript", "PostScript", "PureScript", "TypeScript", "PowerPC", "WebAssembly", "NaN", "NaNs", "OAuth", "GraphQL", "OCaml", "OpenAL", "OpenDNS", "OpenGL", "OpenMP", "OpenSSH", "OpenSSL", "OpenStreetMap", "OpenTelemetry", "OpenType", "WebGL", "WebGL2", "WebGPU", "WebRTC", "WebSocket", "WebTransport", "WebP", "OpenExr", "YCbCr", "sRGB", "TensorFlow", "TrueType", "iOS", "macOS", "FreeBSD", "NetBSD", "OpenBSD", "NixOS", "TeX", "LaTeX", "BibTeX", "BibLaTeX", "MinGW", "CamelCase"])

What it does

Warns if a link reference definition appears at the start of a list item or quote.

Why is this bad?

This is probably intended as an intra-doc link. If it is really supposed to be a reference definition, it can be written outside of the list item or quote.

Example

//! - [link]: description 

Use instead:

//! - [link][]: description (for intra-doc link) //! //! [link]: destination (for link reference definition) 

What it does

Detects overindented list items in doc comments where the continuation lines are indented more than necessary.

Why is this bad?

Overindented list items in doc comments can lead to inconsistent and poorly formatted documentation when rendered. Excessive indentation may cause the text to be misinterpreted as a nested list item or code block, affecting readability and the overall structure of the documentation.

Example

/// - This is the first item in a list /// and this line is overindented. 

Fixes this into:

/// - This is the first item in a list /// and this line is overindented. 

What it does

Detects syntax that looks like a footnote reference.

Rustdoc footnotes are compatible with GitHub-Flavored Markdown (GFM). GFM does not parse a footnote reference unless its definition also exists. This lint checks for footnote references with missing definitions, unless it thinks you’re writing a regex.

Why is this bad?

This probably means that a footnote was meant to exist, but was not written.

Example

/// This is not a footnote[^1], because no definition exists. fn my_fn() {} 

Use instead:

/// This is a footnote[^1]. /// /// [^1]: defined here fn my_fn() {} 

What it does

Checks for double comparisons that could be simplified to a single expression.

Why is this bad?

Readability.

Example

if x == y || x < y {} 

Use instead:

if x <= y {} 

What it does

Checks for Iterator::last being called on a DoubleEndedIterator, which can be replaced with DoubleEndedIterator::next_back.

Why is this bad?

Iterator::last is implemented by consuming the iterator, which is unnecessary if the iterator is a DoubleEndedIterator. Since Rust traits do not allow specialization, Iterator::last cannot be optimized for DoubleEndedIterator.

Example

let last_arg = "echo hello world".split(' ').last(); 

Use instead:

let last_arg = "echo hello world".split(' ').next_back(); 

What it does

Checks for a #[must_use] attribute without further information on functions and methods that return a type already marked as #[must_use].

Why is this bad?

The attribute isn’t needed. Not using the result will already be reported. Alternatively, one can add some text to the attribute to improve the lint message.

Examples

#[must_use] fn double_must_use() -> Result<(), ()> { unimplemented!(); } 

What it does

Checks for unnecessary double parentheses.

Why is this bad?

This makes code harder to read and might indicate a mistake.

Example

fn simple_double_parens() -> i32 { ((0)) } foo((0)); 

Use instead:

fn simple_no_parens() -> i32 { (0) } foo(0); 

What it does

Checks for calls to .drain() that clear the collection, immediately followed by a call to .collect().

“Collection” in this context refers to any type with a drain method: Vec, VecDeque, BinaryHeap, HashSet,HashMap, String

Why is this bad?

Using mem::take is faster as it avoids the allocation. When using mem::take, the old collection is replaced with an empty one and ownership of the old collection is returned.

Known issues

mem::take(&mut vec) is almost equivalent to vec.drain(..).collect(), except that it also moves the capacity. The user might have explicitly written it this way to keep the capacity on the original Vec.

Example

fn remove_all(v: &mut Vec<i32>) -> Vec<i32> { v.drain(..).collect() } 

Use instead:

use std::mem; fn remove_all(v: &mut Vec<i32>) -> Vec<i32> { mem::take(v) } 

What it does

Checks for calls to std::mem::drop with a value that does not implement Drop.

Why is this bad?

Calling std::mem::drop is no different than dropping such a type. A different value may have been intended.

Example

struct Foo; let x = Foo; std::mem::drop(x); 

What it does

Checks for files that are included as modules multiple times.

Why is this bad?

Loading a file as a module more than once causes it to be compiled multiple times, taking longer and putting duplicate content into the module tree.

Example

// lib.rs mod a; mod b; 

// a.rs #[path = "./b.rs"] mod b; 

Use instead:

// lib.rs mod a; mod b; 

// a.rs use crate::b; 

What it does

Checks for function arguments having the similar names differing by an underscore.

Why is this bad?

It affects code readability.

Example

fn foo(a: i32, _a: i32) {} 

Use instead:

fn bar(a: i32, _b: i32) {} 

What it does

Checks for attributes that appear two or more times.

Why is this bad?

Repeating an attribute on the same item (or globally on the same crate) is unnecessary and doesn’t have an effect.

Example

#[allow(dead_code)] #[allow(dead_code)] fn foo() {} 

Use instead:

#[allow(dead_code)] fn foo() {} 

What it does

Checks for calculation of subsecond microseconds or milliseconds from other Duration methods.

Why is this bad?

It’s more concise to call Duration::subsec_micros() or Duration::subsec_millis() than to calculate them.

Example

let micros = duration.subsec_nanos() / 1_000; let millis = duration.subsec_nanos() / 1_000_000; 

Use instead:

let micros = duration.subsec_micros(); let millis = duration.subsec_millis(); 

What it does

Checks for integer validity checks, followed by a transmute that is (incorrectly) evaluated eagerly (e.g. using bool::then_some).

Why is this bad?

Eager evaluation means that the transmute call is executed regardless of whether the condition is true or false. This can introduce unsoundness and other subtle bugs.

Example

Consider the following function which is meant to convert an unsigned integer to its enum equivalent via transmute.

#[repr(u8)] enum Opcode { Add = 0, Sub = 1, Mul = 2, Div = 3 } fn int_to_opcode(op: u8) -> Option<Opcode> { (op < 4).then_some(unsafe { std::mem::transmute(op) }) } 

This may appear fine at first given that it checks that the u8 is within the validity range of the enum, however the transmute is evaluated eagerly, meaning that it executes even if op >= 4!

This makes the function unsound, because it is possible for the caller to cause undefined behavior (creating an enum with an invalid bitpattern) entirely in safe code only by passing an incorrect value, which is normally only a bug that is possible in unsafe code.

One possible way in which this can go wrong practically is that the compiler sees it as:

let temp: Foo = unsafe { std::mem::transmute(op) }; (0 < 4).then_some(temp) 

and optimizes away the (0 < 4) check based on the assumption that since a Foo was created from op with the validity range 0..3, it is impossible for this condition to be false.

In short, it is possible for this function to be optimized in a way that makes it never return None, even if passed the value 4.

This can be avoided by instead using lazy evaluation. For the example above, this should be written:

fn int_to_opcode(op: u8) -> Option<Opcode> { (op < 4).then(|| unsafe { std::mem::transmute(op) }) ^^^^ ^^ `bool::then` only executes the closure if the condition is true! } 

What it does

Checks for lifetime annotations which can be replaced with anonymous lifetimes ('_).

Why is this bad?

The additional lifetimes can make the code look more complicated.

Known problems

This lint ignores functions with where clauses that reference lifetimes to prevent false positives.

Example

fn f<'a>(x: &'a str) -> Chars<'a> { x.chars() } 

Use instead:

fn f(x: &str) -> Chars<'_> { x.chars() } 

What it does

Checks for usage of if expressions with an else if branch, but without a final else branch.

Why restrict this?

Some coding guidelines require this (e.g., MISRA-C:2004 Rule 14.10).

Example

if x.is_positive() { a(); } else if x.is_negative() { b(); } 

Use instead:

if x.is_positive() { a(); } else if x.is_negative() { b(); } else { // We don't care about zero. } 

What it does

Detects documentation that is empty.

Why is this bad?

Empty docs clutter code without adding value, reducing readability and maintainability.

Example

/// fn returns_true() -> bool { true } 

Use instead:

fn returns_true() -> bool { true } 

What it does

Checks for empty Drop implementations.

Why restrict this?

Empty Drop implementations have no effect when dropping an instance of the type. They are most likely useless. However, an empty Drop implementation prevents a type from being destructured, which might be the intention behind adding the implementation as a marker.

Example

struct S; impl Drop for S { fn drop(&mut self) {} } 

Use instead:

struct S; 

What it does

Checks for enums with no variants, which therefore are uninhabited types (cannot be instantiated).

As of this writing, the never_type is still a nightly-only experimental API. Therefore, this lint is only triggered if #![feature(never_type)] is enabled.

Why is this bad?

• If you only want a type which can’t be instantiated, you should use ! (the primitive type “never”), because ! has more extensive compiler support (type inference, etc.) and implementations of common traits.

• If you need to introduce a distinct type, consider using a newtype struct containing ! instead (struct MyType(pub !)), because it is more idiomatic to use a struct rather than an enum when an enum is unnecessary.

  If you do this, note that the visibility of the ! field determines whether the uninhabitedness is visible in documentation, and whether it can be pattern matched to mark code unreachable. If the field is not visible, then the struct acts like any other struct with private fields.

• If the enum has no variants only because all variants happen to be disabled by conditional compilation, then it would be appropriate to allow the lint, with #[allow(empty_enum)].

For further information, visit the never type’s documentation.

Example

enum CannotExist {} 

Use instead:

#![feature(never_type)] /// Use the `!` type directly... type CannotExist = !; /// ...or define a newtype which is distinct. struct CannotExist2(pub !); 

What it does

Finds enum variants without fields that are declared with empty brackets.

Why restrict this?

Empty brackets after a enum variant declaration are redundant and can be omitted, and it may be desirable to do so consistently for style.

However, removing the brackets also introduces a public constant named after the variant, so this is not just a syntactic simplification but an API change, and adding them back is a breaking API change.

Example

enum MyEnum { HasData(u8), HasNoData(), // redundant parentheses NoneHereEither {}, // redundant braces } 

Use instead:

enum MyEnum { HasData(u8), HasNoData, NoneHereEither, } 

What it does

Checks for empty lines after doc comments.

Why is this bad?

The doc comment may have meant to be an inner doc comment, regular comment or applied to some old code that is now commented out. If it was intended to be a doc comment, then the empty line should be removed.

Example

/// Some doc comment with a blank line after it. fn f() {} /// Docs for `old_code` // fn old_code() {} fn new_code() {} 

Use instead:

//! Convert it to an inner doc comment // Or a regular comment /// Or remove the empty line fn f() {} // /// Docs for `old_code` // fn old_code() {} fn new_code() {} 

What it does

Checks for empty lines after outer attributes

Why is this bad?

The attribute may have meant to be an inner attribute (#![attr]). If it was meant to be an outer attribute (#[attr]) then the empty line should be removed

Example

#[allow(dead_code)] fn not_quite_good_code() {} 

Use instead:

// Good (as inner attribute) #![allow(dead_code)] fn this_is_fine() {} // or // Good (as outer attribute) #[allow(dead_code)] fn this_is_fine_too() {} 

What it does

Checks for empty loop expressions.

Why is this bad?

These busy loops burn CPU cycles without doing anything. It is almost always a better idea to panic! than to have a busy loop.

If panicking isn’t possible, think of the environment and either:

• block on something
• sleep the thread for some microseconds
• yield or pause the thread

For std targets, this can be done with std::thread::sleep or std::thread::yield_now.

For no_std targets, doing this is more complicated, especially because #[panic_handler]s can’t panic. To stop/pause the thread, you will probably need to invoke some target-specific intrinsic. Examples include:

• x86_64::instructions::hlt
• cortex_m::asm::wfi

Example

loop {} 

What it does

Finds structs without fields (a so-called “empty struct”) that are declared with brackets.

Why restrict this?

Empty brackets after a struct declaration can be omitted, and it may be desirable to do so consistently for style.

However, removing the brackets also introduces a public constant named after the struct, so this is not just a syntactic simplification but an API change, and adding them back is a breaking API change.

Example

struct Cookie {} struct Biscuit(); 

Use instead:

struct Cookie; struct Biscuit; 

What it does

Checks for C-like enumerations that are repr(isize/usize) and have values that don’t fit into an i32.

Why is this bad?

This will truncate the variant value on 32 bit architectures, but works fine on 64 bit.

Example

#[repr(usize)] enum NonPortable { X = 0x1_0000_0000, Y = 0, } 

What it does

Checks for use Enum::*.

Why is this bad?

It is usually better style to use the prefixed name of an enumeration variant, rather than importing variants.

Known problems

Old-style enumerations that prefix the variants are still around.

Example

use std::cmp::Ordering::*; foo(Less); 

Use instead:

use std::cmp::Ordering; foo(Ordering::Less) 

What it does

Detects enumeration variants that are prefixed or suffixed by the same characters.

Why is this bad?

Enumeration variant names should specify their variant, not repeat the enumeration name.

Limitations

Characters with no casing will be considered when comparing prefixes/suffixes This applies to numbers and non-ascii characters without casing e.g. Foo1 and Foo2 is considered to have different prefixes (the prefixes are Foo1 and Foo2 respectively), as also Bar螃, Bar蟹

Example

enum Cake { BlackForestCake, HummingbirdCake, BattenbergCake, } 

Use instead:

enum Cake { BlackForest, Hummingbird, Battenberg, } 

Configuration

• avoid-breaking-exported-api: Suppress lints whenever the suggested change would cause breakage for other crates.

  (default: true)

• enum-variant-name-threshold: The minimum number of enum variants for the lints about variant names to trigger

  (default: 3)

What it does

Checks for equal operands to comparison, logical and bitwise, difference and division binary operators (==, >, etc., &&, ||, &, |, ^, - and /).

Why is this bad?

This is usually just a typo or a copy and paste error.

Known problems

False negatives: We had some false positives regarding calls (notably racer had one instance of x.pop() && x.pop()), so we removed matching any function or method calls. We may introduce a list of known pure functions in the future.

Example

if x + 1 == x + 1 {} // or assert_eq!(a, a); 

What it does

Checks for pattern matchings that can be expressed using equality.

Why is this bad?

• It reads better and has less cognitive load because equality won’t cause binding.
• It is a Yoda condition. Yoda conditions are widely criticized for increasing the cognitive load of reading the code.
• Equality is a simple bool expression and can be merged with && and || and reuse if blocks

Example

if let Some(2) = x { do_thing(); } 

Use instead:

if x == Some(2) { do_thing(); } 

What it does

Checks for erasing operations, e.g., x * 0.

Why is this bad?

The whole expression can be replaced by zero. This is most likely not the intended outcome and should probably be corrected

Example

let x = 1; 0 / x; 0 * x; x & 0; 

What it does

Checks for .err().expect() calls on the Result type.

Why is this bad?

.expect_err() can be called directly to avoid the extra type conversion from err().

Example

let x: Result<u32, &str> = Ok(10); x.err().expect("Testing err().expect()"); 

Use instead:

let x: Result<u32, &str> = Ok(10); x.expect_err("Testing expect_err"); 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for types named Error that implement Error.

Why restrict this?

It can become confusing when a codebase has 20 types all named Error, requiring either aliasing them in the use statement or qualifying them like my_module::Error. This hinders comprehension, as it requires you to memorize every variation of importing Error used across a codebase.

Example

#[derive(Debug)] pub enum Error { ... } impl std::fmt::Display for Error { ... } impl std::error::Error for Error { ... } 

What it does

Checks for blocks which are nested beyond a certain threshold.

Note: Even though this lint is warn-by-default, it will only trigger if a maximum nesting level is defined in the clippy.toml file.

Why is this bad?

It can severely hinder readability.

Example

An example clippy.toml configuration:

excessive-nesting-threshold = 3 

// lib.rs pub mod a { pub struct X; impl X { pub fn run(&self) { if true { // etc... } } } } 

Use instead:

// a.rs fn private_run(x: &X) { if true { // etc... } } pub struct X; impl X { pub fn run(&self) { private_run(self); } } 

// lib.rs pub mod a; 

Configuration

• excessive-nesting-threshold: The maximum amount of nesting a block can reside in

  (default: 0)

What it does

Checks for float literals with a precision greater than that supported by the underlying type.

The lint is suppressed for literals with over const_literal_digits_threshold digits.

Why is this bad?

Rust will truncate the literal silently.

Example

let v: f32 = 0.123_456_789_9; println!("{}", v); // 0.123_456_789 

Use instead:

let v: f64 = 0.123_456_789_9; println!("{}", v); // 0.123_456_789_9 

Configuration

• const-literal-digits-threshold: The minimum digits a const float literal must have to supress the excessive_precicion lint

  (default: 30)

What it does

Warns on any exported enums that are not tagged #[non_exhaustive]

Why restrict this?

Making an enum exhaustive is a stability commitment: adding a variant is a breaking change. A project may wish to ensure that there are no exhaustive enums or that every exhaustive enum is explicitly #[allow]ed.

Example

enum Foo { Bar, Baz } 

Use instead:

#[non_exhaustive] enum Foo { Bar, Baz } 

What it does

Warns on any exported structs that are not tagged #[non_exhaustive]

Why restrict this?

Making a struct exhaustive is a stability commitment: adding a field is a breaking change. A project may wish to ensure that there are no exhaustive structs or that every exhaustive struct is explicitly #[allow]ed.

Example

struct Foo { bar: u8, baz: String, } 

Use instead:

#[non_exhaustive] struct Foo { bar: u8, baz: String, } 

What it does

Detects calls to the exit() function that are not in the main function. Calls to exit() immediately terminate the program.

Why restrict this?

exit() immediately terminates the program with no information other than an exit code. This provides no means to troubleshoot a problem, and may be an unexpected side effect.

Codebases may use this lint to require that all exits are performed either by panicking (which produces a message, a code location, and optionally a backtrace) or by calling exit() from main() (which is a single place to look).

Good example

fn main() { std::process::exit(0); } 

Bad example

fn main() { other_function(); } fn other_function() { std::process::exit(0); } 

Use instead:

// To provide a stacktrace and additional information panic!("message"); // or a main method with a return fn main() -> Result<(), i32> { Ok(()) } 

What it does

Checks for calls to .expect(&format!(...)), .expect(foo(..)), etc., and suggests to use unwrap_or_else instead

Why is this bad?

The function will always be called.

Known problems

If the function has side-effects, not calling it will change the semantics of the program, but you shouldn’t rely on that anyway.

Example

foo.expect(&format!("Err {}: {}", err_code, err_msg)); // or foo.expect(format!("Err {}: {}", err_code, err_msg).as_str()); 

Use instead:

foo.unwrap_or_else(|| panic!("Err {}: {}", err_code, err_msg)); 

What it does

Checks for .expect() or .expect_err() calls on Results and .expect() call on Options.

Why restrict this?

Usually it is better to handle the None or Err case. Still, for a lot of quick-and-dirty code, expect is a good choice, which is why this lint is Allow by default.

result.expect() will let the thread panic on Err values. Normally, you want to implement more sophisticated error handling, and propagate errors upwards with ? operator.

Examples

option.expect("one"); result.expect("one"); 

Use instead:

option?; // or result?; 

Past names

• option_expect_used
• result_expect_used

Configuration

• allow-expect-in-consts: Whether expect should be allowed in code always evaluated at compile time

  (default: true)

• allow-expect-in-tests: Whether expect should be allowed in test functions or #[cfg(test)]

  (default: false)

What it does

Checks for explicit Clone implementations for Copy types.

Why is this bad?

To avoid surprising behavior, these traits should agree and the behavior of Copy cannot be overridden. In almost all situations a Copy type should have a Clone implementation that does nothing more than copy the object, which is what #[derive(Copy, Clone)] gets you.

Example

#[derive(Copy)] struct Foo; impl Clone for Foo { // .. } 

What it does

Checks for dereferencing expressions which would be covered by auto-deref.

Why is this bad?

This unnecessarily complicates the code.

Example

let x = String::new(); let y: &str = &*x; 

Use instead:

let x = String::new(); let y: &str = &x; 

What it does

Checks for loops over slices with an explicit counter and suggests the use of .enumerate().

Why is this bad?

Using .enumerate() makes the intent more clear, declutters the code and may be faster in some instances.

Example

let mut i = 0; for item in &v { bar(i, *item); i += 1; } 

Use instead:

for (i, item) in v.iter().enumerate() { bar(i, *item); } 

What it does

Checks for explicit deref() or deref_mut() method calls.

Why is this bad?

Dereferencing by &*x or &mut *x is clearer and more concise, when not part of a method chain.

Example

use std::ops::Deref; let a: &mut String = &mut String::from("foo"); let b: &str = a.deref(); 

Use instead:

let a: &mut String = &mut String::from("foo"); let b = &*a; 

This lint excludes all of:

let _ = d.unwrap().deref(); let _ = Foo::deref(&foo); let _ = <Foo as Deref>::deref(&foo); 

What it does

Checks for loops on y.into_iter() where y will do, and suggests the latter.

Why is this bad?

Readability.

Example

// with `y` a `Vec` or slice: for x in y.into_iter() { // .. } 

can be rewritten to

for x in y { // .. } 

What it does

Checks for loops on x.iter() where &x will do, and suggests the latter.

Why is this bad?

Readability.

Known problems

False negatives. We currently only warn on some known types.

Example

// with `y` a `Vec` or slice: for x in y.iter() { // .. } 

Use instead:

for x in &y { // .. } 

Configuration

• enforce-iter-loop-reborrow: Whether to recommend using implicit into iter for reborrowed values.

Example

let mut vec = vec![1, 2, 3]; let rmvec = &mut vec; for _ in rmvec.iter() {} for _ in rmvec.iter_mut() {} 

Use instead:

let mut vec = vec![1, 2, 3]; let rmvec = &mut vec; for _ in &*rmvec {} for _ in &mut *rmvec {} 

(default: false)

What it does

Checks for usage of write!() / writeln()! which can be replaced with (e)print!() / (e)println!()

Why is this bad?

Using (e)println! is clearer and more concise

Example

writeln!(&mut std::io::stderr(), "foo: {:?}", bar).unwrap(); writeln!(&mut std::io::stdout(), "foo: {:?}", bar).unwrap(); 

Use instead:

eprintln!("foo: {:?}", bar); println!("foo: {:?}", bar); 

What it does

Nothing. This lint has been deprecated

Deprecation reason

Vec::extend_from_slice is no longer faster than Vec::extend due to specialization.

What it does

Checks for occurrences where one vector gets extended instead of append

Why is this bad?

Using append instead of extend is more concise and faster

Example

let mut a = vec![1, 2, 3]; let mut b = vec![4, 5, 6]; a.extend(b.drain(..)); 

Use instead:

let mut a = vec![1, 2, 3]; let mut b = vec![4, 5, 6]; a.append(&mut b); 

What it does

Checks for lifetimes in generics that are never used anywhere else.

Why is this bad?

The additional lifetimes make the code look more complicated, while there is nothing out of the ordinary going on. Removing them leads to more readable code.

Example

// unnecessary lifetimes fn unused_lifetime<'a>(x: u8) { // .. } 

Use instead:

fn no_lifetime(x: u8) { // ... } 

What it does

Checks for type parameters in generics that are never used anywhere else.

Why is this bad?

Functions cannot infer the value of unused type parameters; therefore, calling them requires using a turbofish, which serves no purpose but to satisfy the compiler.

Example

fn unused_ty<T>(x: u8) { // .. } 

Use instead:

fn no_unused_ty(x: u8) { // .. } 

What it does

Checks for impls of From<..> that contain panic!() or unwrap()

Why is this bad?

TryFrom should be used if there’s a possibility of failure.

Example

struct Foo(i32); impl From<String> for Foo { fn from(s: String) -> Self { Foo(s.parse().unwrap()) } } 

Use instead:

struct Foo(i32); impl TryFrom<String> for Foo { type Error = (); fn try_from(s: String) -> Result<Self, Self::Error> { if let Ok(parsed) = s.parse() { Ok(Foo(parsed)) } else { Err(()) } } } 

What it does

Checks for immediate reassignment of fields initialized with Default::default().

Why is this bad?

It’s more idiomatic to use the functional update syntax.

Known problems

Assignments to patterns that are of tuple type are not linted.

Example

let mut a: A = Default::default(); a.i = 42; 

Use instead:

let a = A { i: 42, .. Default::default() }; 

What it does

Checks for usage of scoped visibility modifiers, like pub(crate), on fields. These make a field visible within a scope between public and private.

Why restrict this?

Scoped visibility modifiers cause a field to be accessible within some scope between public and private, potentially within an entire crate. This allows for fields to be non-private while upholding internal invariants, but can be a code smell. Scoped visibility requires checking a greater area, potentially an entire crate, to verify that an invariant is upheld, and global analysis requires a lot of effort.

Example

pub mod public_module { struct MyStruct { pub(crate) first_field: bool, pub(super) second_field: bool } } 

Use instead:

pub mod public_module { struct MyStruct { first_field: bool, second_field: bool } impl MyStruct { pub(crate) fn get_first_field(&self) -> bool { self.first_field } pub(super) fn get_second_field(&self) -> bool { self.second_field } } } 

What it does

Checks for FileType::is_file().

Why restrict this?

When people testing a file type with FileType::is_file they are testing whether a path is something they can get bytes from. But is_file doesn’t cover special file types in unix-like systems, and doesn’t cover symlink in windows. Using !FileType::is_dir() is a better way to that intention.

Example

let metadata = std::fs::metadata("foo.txt")?; let filetype = metadata.file_type(); if filetype.is_file() { // read file } 

should be written as:

let metadata = std::fs::metadata("foo.txt")?; let filetype = metadata.file_type(); if !filetype.is_dir() { // read file } 

What it does

Checks for usage of bool::then in Iterator::filter_map.

Why is this bad?

This can be written with filter then map instead, which would reduce nesting and separates the filtering from the transformation phase. This comes with no cost to performance and is just cleaner.

Limitations

Does not lint bool::then_some, as it eagerly evaluates its arguments rather than lazily. This can create differing behavior, so better safe than sorry.

Example

_ = v.into_iter().filter_map(|i| (i % 2 == 0).then(|| really_expensive_fn(i))); 

Use instead:

_ = v.into_iter().filter(|i| i % 2 == 0).map(|i| really_expensive_fn(i)); 

What it does

Checks for usage of filter_map(|x| x).

Why is this bad?

Readability, this can be written more concisely by using flatten.

Example

iter.filter_map(|x| x); 

Use instead:

iter.flatten(); 

What it does

Checks for usage of _.filter_map(_).next().

Why is this bad?

Readability, this can be written more concisely as _.find_map(_).

Example

 (0..3).filter_map(|x| if x == 2 { Some(x) } else { None }).next(); 

Can be written as

 (0..3).find_map(|x| if x == 2 { Some(x) } else { None }); 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for usage of _.filter(_).next().

Why is this bad?

Readability, this can be written more concisely as _.find(_).

Example

vec.iter().filter(|x| **x == 0).next(); 

Use instead:

vec.iter().find(|x| **x == 0); 

What it does

Checks for usage of flat_map(|x| x).

Why is this bad?

Readability, this can be written more concisely by using flatten.

Example

iter.flat_map(|x| x); 

Can be written as

iter.flatten(); 

What it does

Checks for usage of Iterator::flat_map() where filter_map() could be used instead.

Why is this bad?

filter_map() is known to always produce 0 or 1 output items per input item, rather than however many the inner iterator type produces. Therefore, it maintains the upper bound in Iterator::size_hint(), and communicates to the reader that the input items are not being expanded into multiple output items without their having to notice that the mapping function returns an Option.

Example

let nums: Vec<i32> = ["1", "2", "whee!"].iter().flat_map(|x| x.parse().ok()).collect(); 

Use instead:

let nums: Vec<i32> = ["1", "2", "whee!"].iter().filter_map(|x| x.parse().ok()).collect(); 

What it does

Checks for float arithmetic.

Why restrict this?

For some embedded systems or kernel development, it can be useful to rule out floating-point numbers.

Example

a + 1.0; 

What it does

Checks for (in-)equality comparisons on floating-point values (apart from zero), except in functions called *eq* (which probably implement equality for a type involving floats).

Why is this bad?

Floating point calculations are usually imprecise, so asking if two values are exactly equal is asking for trouble because arriving at the same logical result via different routes (e.g. calculation versus constant) may yield different values.

Example

let a: f64 = 1000.1; let b: f64 = 0.2; let x = a + b; let y = 1000.3; // Expected value. // Actual value: 1000.3000000000001 println!("{x}"); let are_equal = x == y; println!("{are_equal}"); // false 

The correct way to compare floating point numbers is to define an allowed error margin. This may be challenging if there is no “natural” error margin to permit. Broadly speaking, there are two cases:

1. If your values are in a known range and you can define a threshold for “close enough to be equal”, it may be appropriate to define an absolute error margin. For example, if your data is “length of vehicle in centimeters”, you may consider 0.1 cm to be “close enough”.
2. If your code is more general and you do not know the range of values, you should use a relative error margin, accepting e.g. 0.1% of error regardless of specific values.

For the scenario where you can define a meaningful absolute error margin, consider using:

let a: f64 = 1000.1; let b: f64 = 0.2; let x = a + b; let y = 1000.3; // Expected value. const ALLOWED_ERROR_VEHICLE_LENGTH_CM: f64 = 0.1; let within_tolerance = (x - y).abs() < ALLOWED_ERROR_VEHICLE_LENGTH_CM; println!("{within_tolerance}"); // true 

NB! Do not use f64::EPSILON - while the error margin is often called “epsilon”, this is a different use of the term that is not suitable for floating point equality comparison. Indeed, for the example above using f64::EPSILON as the allowed error would return false.

For the scenario where no meaningful absolute error can be defined, refer to the floating point guide for a reference implementation of relative error based comparison of floating point values. MIN_NORMAL in the reference implementation is equivalent to MIN_POSITIVE in Rust.

What it does

Checks for (in-)equality comparisons on constant floating-point values (apart from zero), except in functions called *eq* (which probably implement equality for a type involving floats).

Why restrict this?

Floating point calculations are usually imprecise, so asking if two values are exactly equal is asking for trouble because arriving at the same logical result via different routes (e.g. calculation versus constant) may yield different values.

Example

let a: f64 = 1000.1; let b: f64 = 0.2; let x = a + b; const Y: f64 = 1000.3; // Expected value. // Actual value: 1000.3000000000001 println!("{x}"); let are_equal = x == Y; println!("{are_equal}"); // false 

The correct way to compare floating point numbers is to define an allowed error margin. This may be challenging if there is no “natural” error margin to permit. Broadly speaking, there are two cases:

1. If your values are in a known range and you can define a threshold for “close enough to be equal”, it may be appropriate to define an absolute error margin. For example, if your data is “length of vehicle in centimeters”, you may consider 0.1 cm to be “close enough”.
2. If your code is more general and you do not know the range of values, you should use a relative error margin, accepting e.g. 0.1% of error regardless of specific values.

For the scenario where you can define a meaningful absolute error margin, consider using:

let a: f64 = 1000.1; let b: f64 = 0.2; let x = a + b; const Y: f64 = 1000.3; // Expected value. const ALLOWED_ERROR_VEHICLE_LENGTH_CM: f64 = 0.1; let within_tolerance = (x - Y).abs() < ALLOWED_ERROR_VEHICLE_LENGTH_CM; println!("{within_tolerance}"); // true 

NB! Do not use f64::EPSILON - while the error margin is often called “epsilon”, this is a different use of the term that is not suitable for floating point equality comparison. Indeed, for the example above using f64::EPSILON as the allowed error would return false.

For the scenario where no meaningful absolute error can be defined, refer to the floating point guide for a reference implementation of relative error based comparison of floating point values. MIN_NORMAL in the reference implementation is equivalent to MIN_POSITIVE in Rust.

What it does

Checks for statements of the form (a - b) < f32::EPSILON or (a - b) < f64::EPSILON. Notes the missing .abs().

Why is this bad?

The code without .abs() is more likely to have a bug.

Known problems

If the user can ensure that b is larger than a, the .abs() is technically unnecessary. However, it will make the code more robust and doesn’t have any large performance implications. If the abs call was deliberately left out for performance reasons, it is probably better to state this explicitly in the code, which then can be done with an allow.

Example

pub fn is_roughly_equal(a: f32, b: f32) -> bool { (a - b) < f32::EPSILON } 

Use instead:

pub fn is_roughly_equal(a: f32, b: f32) -> bool { (a - b).abs() < f32::EPSILON } 

What it does

Checks for excessive use of bools in function definitions.

Why is this bad?

Calls to such functions are confusing and error prone, because it’s hard to remember argument order and you have no type system support to back you up. Using two-variant enums instead of bools often makes API easier to use.

Example

fn f(is_round: bool, is_hot: bool) { ... } 

Use instead:

enum Shape { Round, Spiky, } enum Temperature { Hot, IceCold, } fn f(shape: Shape, temperature: Temperature) { ... } 

Configuration

• max-fn-params-bools: The maximum number of bool parameters a function can have

  (default: 3)

What it does

Checks for casts of function pointers to something other than usize.

Why is this bad?

Casting a function pointer to anything other than usize/isize is not portable across architectures. If the target type is too small the address would be truncated, and target types larger than usize are unnecessary.

Casting to isize also doesn’t make sense, since addresses are never signed.

Example

fn fun() -> i32 { 1 } let _ = fun as i64; 

Use instead:

let _ = fun as usize; 

What it does

Checks for casts of a function pointer to any integer type.

Why restrict this?

Casting a function pointer to an integer can have surprising results and can occur accidentally if parentheses are omitted from a function call. If you aren’t doing anything low-level with function pointers then you can opt out of casting functions to integers in order to avoid mistakes. Alternatively, you can use this lint to audit all uses of function pointer casts in your code.

Example

// fn1 is cast as `usize` fn fn1() -> u16 { 1 }; let _ = fn1 as usize; 

Use instead:

// maybe you intended to call the function? fn fn2() -> u16 { 1 }; let _ = fn2() as usize; // or // maybe you intended to cast it to a function type? fn fn3() -> u16 { 1 } let _ = fn3 as fn() -> u16; 

What it does

Checks for casts of a function pointer to a numeric type not wide enough to store an address.

Why is this bad?

Such a cast discards some bits of the function’s address. If this is intended, it would be more clearly expressed by casting to usize first, then casting the usize to the intended type (with a comment) to perform the truncation.

Example

fn fn1() -> i16 { 1 }; let _ = fn1 as i32; 

Use instead:

// Cast to usize first, then comment with the reason for the truncation fn fn1() -> i16 { 1 }; let fn_ptr = fn1 as usize; let fn_ptr_truncated = fn_ptr as i32; 

What it does

Checks for iterating a map (HashMap or BTreeMap) and ignoring either the keys or values.

Why is this bad?

Readability. There are keys and values methods that can be used to express that don’t need the values or keys.

Example

for (k, _) in &map { .. } 

could be replaced by

for k in map.keys() { .. } 

What it does

Checks for calls to std::mem::forget with a value that does not implement Drop.

Why is this bad?

Calling std::mem::forget is no different than dropping such a type. A different value may have been intended.

Example

struct Foo; let x = Foo; std::mem::forget(x); 

What it does

Checks for usage of .map(|_| format!(..)).collect::<String>().

Why is this bad?

This allocates a new string for every element in the iterator. This can be done more efficiently by creating the String once and appending to it in Iterator::fold, using either the write! macro which supports exactly the same syntax as the format! macro, or concatenating with + in case the iterator yields &str/String.

Note also that write!-ing into a String can never fail, despite the return type of write! being std::fmt::Result, so it can be safely ignored or unwrapped.

Example

fn hex_encode(bytes: &[u8]) -> String { bytes.iter().map(|b| format!("{b:02X}")).collect() } 

Use instead:

use std::fmt::Write; fn hex_encode(bytes: &[u8]) -> String { bytes.iter().fold(String::new(), |mut output, b| { let _ = write!(output, "{b:02X}"); output }) } 

What it does

Detects format! within the arguments of another macro that does formatting such as format! itself, write! or println!. Suggests inlining the format! call.

Why is this bad?

The recommended code is both shorter and avoids a temporary allocation.

Example

println!("error: {}", format!("something failed at {}", Location::caller())); 

Use instead:

println!("error: something failed at {}", Location::caller()); 

What it does

Detects cases where the result of a format! call is appended to an existing String.

Why is this bad?

Introduces an extra, avoidable heap allocation.

Known problems

format! returns a String but write! returns a Result. Thus you are forced to ignore the Err variant to achieve the same API.

While using write! in the suggested way should never fail, this isn’t necessarily clear to the programmer.

Example

let mut s = String::new(); s += &format!("0x{:X}", 1024); s.push_str(&format!("0x{:X}", 1024)); 

Use instead:

use std::fmt::Write as _; // import without risk of name clashing let mut s = String::new(); let _ = write!(s, "0x{:X}", 1024); 

What it does

Checks for outer doc comments written with 4 forward slashes (////).

Why is this bad?

This is (probably) a typo, and results in it not being a doc comment; just a regular comment.

Example

//// My amazing data structure pub struct Foo { // ... } 

Use instead:

/// My amazing data structure pub struct Foo { // ... } 

What it does

Checks for from_iter() function calls on types that implement the FromIterator trait.

Why is this bad?

If it’s needed to create a collection from the contents of an iterator, the Iterator::collect(_) method is preferred. However, when it’s needed to specify the container type, Vec::from_iter(_) can be more readable than using a turbofish (e.g. _.collect::<Vec<_>>()). See FromIterator documentation

Example

let five_fives = std::iter::repeat(5).take(5); let v = Vec::from_iter(five_fives); assert_eq!(v, vec![5, 5, 5, 5, 5]); 

Use instead:

let five_fives = std::iter::repeat(5).take(5); let v: Vec<i32> = five_fives.collect(); assert_eq!(v, vec![5, 5, 5, 5, 5]); 

but prefer to use

let numbers: Vec<i32> = FromIterator::from_iter(1..=5); 

instead of

let numbers = (1..=5).collect::<Vec<_>>(); 

What it does

Searches for implementations of the Into<..> trait and suggests to implement From<..> instead.

Why is this bad?

According the std docs implementing From<..> is preferred since it gives you Into<..> for free where the reverse isn’t true.

Example

struct StringWrapper(String); impl Into<StringWrapper> for String { fn into(self) -> StringWrapper { StringWrapper(self) } } 

Use instead:

struct StringWrapper(String); impl From<String> for StringWrapper { fn from(s: String) -> StringWrapper { StringWrapper(s) } } 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks if we’re passing a c_void raw pointer to {Box,Rc,Arc,Weak}::from_raw(_)

Why is this bad?

When dealing with c_void raw pointers in FFI, it is easy to run into the pitfall of calling from_raw with the c_void pointer. The type signature of Box::from_raw is fn from_raw(raw: *mut T) -> Box<T>, so if you pass a *mut c_void you will get a Box<c_void> (and similarly for Rc, Arc and Weak). For this to be safe, c_void would need to have the same memory layout as the original type, which is often not the case.

Example

let ptr = Box::into_raw(Box::new(42usize)) as *mut c_void; let _ = unsafe { Box::from_raw(ptr) }; 

Use instead:

let _ = unsafe { Box::from_raw(ptr as *mut usize) }; 

What it does

Checks for function invocations of the form primitive::from_str_radix(s, 10)

Why is this bad?

This specific common use case can be rewritten as s.parse::<primitive>() (and in most cases, the turbofish can be removed), which reduces code length and complexity.

Known problems

This lint may suggest using (&<expression>).parse() instead of <expression>.parse() directly in some cases, which is correct but adds unnecessary complexity to the code.

Example

let input: &str = get_input(); let num = u16::from_str_radix(input, 10)?; 

Use instead:

let input: &str = get_input(); let num: u16 = input.parse()?; 

What it does

This lint requires Future implementations returned from functions and methods to implement the Send marker trait, ignoring type parameters.

If a function is generic and its Future conditionally implements Send based on a generic parameter then it is considered Send and no warning is emitted.

This can be used by library authors (public and internal) to ensure their functions are compatible with both multi-threaded runtimes that require Send futures, as well as single-threaded runtimes where callers may choose !Send types for generic parameters.

Why is this bad?

A Future implementation captures some state that it needs to eventually produce its final value. When targeting a multithreaded executor (which is the norm on non-embedded devices) this means that this state may need to be transported to other threads, in other words the whole Future needs to implement the Send marker trait. If it does not, then the resulting Future cannot be submitted to a thread pool in the end user’s code.

Especially for generic functions it can be confusing to leave the discovery of this problem to the end user: the reported error location will be far from its cause and can in many cases not even be fixed without modifying the library where the offending Future implementation is produced.

Example

async fn not_send(bytes: std::rc::Rc<[u8]>) {} 

Use instead:

async fn is_send(bytes: std::sync::Arc<[u8]>) {} 

What it does

Checks for usage of x.get(0) instead of x.first() or x.front().

Why is this bad?

Using x.first() for Vecs and slices or x.front() for VecDeques is easier to read and has the same result.

Example

let x = vec![2, 3, 5]; let first_element = x.get(0); 

Use instead:

let x = vec![2, 3, 5]; let first_element = x.first(); 

What it does

Checks for usage of x.get(x.len() - 1) instead of x.last().

Why is this bad?

Using x.last() is easier to read and has the same result.

Note that using x[x.len() - 1] is semantically different from x.last(). Indexing into the array will panic on out-of-bounds accesses, while x.get() and x.last() will return None.

There is another lint (get_unwrap) that covers the case of using x.get(index).unwrap() instead of x[index].

Example

let x = vec![2, 3, 5]; let last_element = x.get(x.len() - 1); 

Use instead:

let x = vec![2, 3, 5]; let last_element = x.last(); 

What it does

Checks for usage of .get().unwrap() (or .get_mut().unwrap) on a standard library type which implements Index

Why restrict this?

Using the Index trait ([]) is more clear and more concise.

Known problems

Not a replacement for error handling: Using either .unwrap() or the Index trait ([]) carries the risk of causing a panic if the value being accessed is None. If the use of .get().unwrap() is a temporary placeholder for dealing with the Option type, then this does not mitigate the need for error handling. If there is a chance that .get() will be None in your program, then it is advisable that the None case is handled in a future refactor instead of using .unwrap() or the Index trait.

Example

let mut some_vec = vec![0, 1, 2, 3]; let last = some_vec.get(3).unwrap(); *some_vec.get_mut(0).unwrap() = 1; 

The correct use would be:

let mut some_vec = vec![0, 1, 2, 3]; let last = some_vec[3]; some_vec[0] = 1; 

What it does

Checks for the usage of the to_ne_bytes method and/or the function from_ne_bytes.

Why restrict this?

To ensure use of explicitly chosen endianness rather than the target’s endianness, such as when implementing network protocols or file formats rather than FFI.

Example

let _x = 2i32.to_ne_bytes(); let _y = 2i64.to_ne_bytes(); 

What it does

Checks for identity operations, e.g., x + 0.

Why is this bad?

This code can be removed without changing the meaning. So it just obscures what’s going on. Delete it mercilessly.

Example

x / 1 + 0 * 1 - 0 | 0; 

What it does

Checks for Mutex::lock calls in if let expression with lock calls in any of the else blocks.

Disabled starting in Edition 2024

This lint is effectively disabled starting in Edition 2024 as if let ... else scoping was reworked such that this is no longer an issue. See Proposal: stabilize if_let_rescope for Edition 2024

Why is this bad?

The Mutex lock remains held for the whole if let ... else block and deadlocks.

Example

if let Ok(thing) = mutex.lock() { do_thing(); } else { mutex.lock(); } 

Should be written

let locked = mutex.lock(); if let Ok(thing) = locked { do_thing(thing); } else { use_locked(locked); } 

What it does

Checks for usage of ! or != in an if condition with an else branch.

Why is this bad?

Negations reduce the readability of statements.

Example

if !v.is_empty() { a() } else { b() } 

Could be written:

if v.is_empty() { b() } else { a() } 

What it does

Checks for if/else with the same body as the then part and the else part.

Why is this bad?

This is probably a copy & paste error.

Example

let foo = if … { 42 } else { 42 }; 

What it does

Checks for if-else that could be written using either bool::then or bool::then_some.

Why restrict this?

Looks a little redundant. Using bool::then is more concise and incurs no loss of clarity. For simple calculations and known values, use bool::then_some, which is eagerly evaluated in comparison to bool::then.

Example

let a = if v.is_empty() { println!("true!"); Some(42) } else { None }; 

Could be written:

let a = v.is_empty().then(|| { println!("true!"); 42 }); 

Configuration

• msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml

  (default: current version)

What it does

Checks for consecutive ifs with the same condition.

Why is this bad?

This is probably a copy & paste error.

Example

if a == b { … } else if a == b { … } 

Note that this lint ignores all conditions with a function call as it could have side effects: