From 6814c39f8c8358b24a0358afdcfcec3af12de1ac Mon Sep 17 00:00:00 2001 From: GHA CI Date: Thu, 9 Jan 2025 17:10:31 +0000 Subject: [PATCH] Automatic deploy to GitHub Pages (beta): 609cd310be44677ae31d452a17b0f8207e1abfe1 --- beta/index.html | 673 ++++++++++++++++++++++++++++-------------------- beta/script.js | 14 +- 2 files changed, 394 insertions(+), 293 deletions(-) diff --git a/beta/index.html b/beta/index.html index ca4d4709f944..736062754bcb 100644 --- a/beta/index.html +++ b/beta/index.html @@ -115,7 +115,7 @@

Configuration

(default: current version)

-
Applicability: MachineApplicable(?)
Added in: 1.70.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.70.0
Related Issues
View Source

What it does

Checks for attributes that allow lints without a reason.

Why restrict this?

Justifying each allow helps readers understand the reasoning, @@ -133,7 +133,7 @@

Configuration

(default: current version)

-
Applicability: Unspecified(?)
Added in: 1.61.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.61.0
Related Issues
View Source

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?

@@ -193,7 +193,7 @@

Configuration

(default: current version)

-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

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 @@ -297,7 +297,7 @@

Configuration

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

-
Applicability: Unspecified(?)
Added in: 1.82.0
Related Issues
View Source

What it does.

+
Applicability: Unspecified(?)
Added in: 1.84.0
Related Issues
View Source

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 @@ -398,7 +398,23 @@

Example

f(a.try_into().expect("Unexpected u16 overflow in f")); -
Applicability: Unspecified(?)
Added in: 1.41.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.41.0
Related Issues
View Source

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
+}
+
+
Applicability: MachineApplicable(?)
Added in: 1.81.0
Related Issues
View Source

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 @@ -413,7 +429,7 @@

Example

let ptr = vec.as_mut_ptr(); unsafe { ptr.write(4) }; -
Applicability: MaybeIncorrect(?)
Added in: 1.66.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.66.0
Related Issues
View Source

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 @@ -429,7 +445,7 @@

Example

let n: u16 = 256; foo(n as usize); -
Applicability: MachineApplicable(?)
Added in: 1.63.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.63.0
Related Issues
View Source

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 @@ -570,7 +586,7 @@

Configuration

(default: [])

-
Applicability: Unspecified(?)
Added in: 1.62.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.62.0
Related Issues
View Source

What it does

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

Why is this bad?

@@ -618,7 +634,7 @@

Example

baz().await; } -
Applicability: Unspecified(?)
Added in: 1.45.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.45.0
Related Issues
View Source

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 @@ -659,7 +675,7 @@

Example

baz().await; } -
Applicability: Unspecified(?)
Added in: 1.49.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.49.0
Related Issues
View Source

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 @@ -720,7 +736,7 @@

Example

Use instead:

#![deny(clippy::as_conversions)]
-
Applicability: Unspecified(?)
Added in: 1.47.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.47.0
Related Issues
View Source

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?

@@ -798,12 +814,12 @@

Example

Applicability: MaybeIncorrect(?)
Added in: 1.65.0
Related Issues
View Source

What it does

Checks for the usage of &expr as *const T or -&mut expr as *mut T, and suggest using ptr::addr_of or -ptr::addr_of_mut instead.

+&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 ptr::addr_of docs for more information.

+Read the &raw explanation in the Reference for more information.

Example

let val = 1;
 let p = &val as *const i32;
@@ -813,10 +829,10 @@ 
Example

Use instead:

let val = 1;
-let p = std::ptr::addr_of!(val);
+let p = &raw const val;
 
 let mut val_mut = 1;
-let p_mut = std::ptr::addr_of_mut!(val_mut);
+let p_mut = &raw mut val_mut;

Configuration

    @@ -825,7 +841,7 @@

    Configuration

    (default: current version)

-
Applicability: MachineApplicable(?)
Added in: 1.60.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.60.0
Related Issues
View Source

What it does

Checks for &*(&T).

Why is this bad?

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

@@ -1020,7 +1036,7 @@

Example

"hello".len();
 String::from("hello").len();
-
Applicability: MachineApplicable(?)
Added in: 1.62.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.62.0
Related Issues
View Source

What it does

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

Why is this bad?

.as_bytes().get() is more efficient and more @@ -1031,7 +1047,7 @@

Example

Use instead:

"Hello".as_bytes().get(3);
-
Applicability: MachineApplicable(?)
Added in: 1.52.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.52.0
Related Issues
View Source

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?

@@ -1082,7 +1098,7 @@

Example

.map_or(false, |ext| ext.eq_ignore_ascii_case("rs")) } -
Applicability: MaybeIncorrect(?)
Added in: 1.51.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.51.0
Related Issues
View Source

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.

@@ -1101,7 +1117,7 @@

Configuration

(default: current version)

-
Applicability: MachineApplicable(?)
Added in: 1.62.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.62.0
Related Issues
View Source

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.

@@ -1109,7 +1125,7 @@

Example

enum E { X(i32) };
 let _ = E::X as usize;
-
Applicability: Unspecified(?)
Added in: 1.61.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.61.0
Related Issues
View Source

What it does

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

Why is this bad?

@@ -1118,7 +1134,7 @@

Example

enum E { X = 256 };
 let _ = E::X as u8;
-
Applicability: Unspecified(?)
Added in: 1.61.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.61.0
Related Issues
View Source

What it does

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

Why is this bad?

@@ -1138,7 +1154,7 @@

Example

u64::from(x) } -
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

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 @@ -1149,7 +1165,7 @@

Example

Use instead:

let _ = 0_u64;
-
Applicability: Unspecified(?)
Added in: 1.66.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.66.0
Related Issues
View Source

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, @@ -1177,7 +1193,7 @@

Example

x as u16 } -
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

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 @@ -1191,7 +1207,7 @@

Why is this bad?

Example

u32::MAX as i32; // will yield a value of `-1`
-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

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 @@ -1206,7 +1222,7 @@

Example

let x = u64::MAX;
 x as f64;
-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

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?

@@ -1223,7 +1239,7 @@

Example

(&1u8 as *const u8).cast::<u16>(); (&mut 1u8 as *mut u8).cast::<u16>(); -
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

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 @@ -1235,7 +1251,7 @@

Example

let y: i8 = -1;
 y as u128; // will return 18446744073709551615
-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

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 @@ -1268,7 +1284,7 @@

Example

println!("{:?}", &*new_ptr); } -
Applicability: HasPlaceholders(?)
Added in: 1.61.0
Related Issues
View Source

What it does

+
Applicability: HasPlaceholders(?)
Added in: 1.61.0
Related Issues
View Source

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 @@ -1283,7 +1299,7 @@

Example

let _: *const [u8] = std::ptr::slice_from_raw_parts(ptr, len);
 let _: *mut [u8] = std::ptr::slice_from_raw_parts_mut(ptr, len);
-
Applicability: MachineApplicable(?)
Added in: 1.65.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.65.0
Related Issues
View Source

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. @@ -1310,7 +1326,7 @@

Example

A better version, using the byte literal:

b'x'
-
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

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?

@@ -1366,7 +1382,7 @@

Example

let mut v = vec![1, 2, 3];
 v.clear();
-
Applicability: MachineApplicable(?)
Added in: 1.70.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.70.0
Related Issues
View Source

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 @@ -1461,7 +1477,7 @@

Configuration

(default: 25)

-
Applicability: Unspecified(?)
Added in: 1.35.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.35.0
Related Issues
View Source

What it does

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

Why is this bad?

@@ -1535,7 +1551,7 @@

Configuration

(default: current version)

-
Applicability: Unspecified(?)
Added in: 1.50.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.50.0
Related Issues
View Source

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?

@@ -1608,7 +1624,7 @@

Example

} } -
Applicability: Unspecified(?)
Added in: 1.40.0
Related Issues
View Source

What it does

+
Applicability: HasPlaceholders(?)
Added in: 1.40.0
Related Issues
View Source

What it does

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

Why is this bad?

@@ -1649,7 +1665,7 @@

Example

Use instead:

println!("the string is empty");
-
Applicability: Unspecified(?)
Added in: 1.79.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.79.0
Related Issues
View Source

What it does

Checks for types that implement Copy as well as Iterator.

Why is this bad?

@@ -1856,14 +1872,15 @@

Example

Why restrict this?

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

Known problems

-

This lint can only be allowed at the function level or above.

+

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 = 10i32;
-let f = 1.23f64;
+
let i = 10_i32;
+let f = 1.23_f64;
Applicability: MaybeIncorrect(?)
Added in: 1.52.0
Related Issues
View Source

What it does

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

@@ -1933,7 +1950,7 @@

Configuration

(default: current version)

-
Applicability: MachineApplicable(?)
Added in: 1.32.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.32.0
Related Issues
View Source

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)].

@@ -1947,7 +1964,7 @@

Example

#[cfg(clippy)]
 struct Bar;
-
Applicability: MachineApplicable(?)
Added in: 1.78.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.78.0
Related Issues
View Source

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.

@@ -1958,7 +1975,7 @@

Example

#[deprecated(since = "forever")]
 fn something_else() { /* ... */ }
-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

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

Why is this bad?

Immediately dereferencing a reference is no-op and @@ -2060,7 +2077,7 @@

Example

#[derive(Ord, PartialOrd, PartialEq, Eq)]
 struct Foo;
-
Applicability: Unspecified(?)
Added in: 1.47.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.47.0
Related Issues
View Source

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, @@ -2081,7 +2098,7 @@

Example

i_am_eq_too: Vec<String>, } -
Applicability: MachineApplicable(?)
Added in: 1.63.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.63.0
Related Issues
View Source

What it does

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

Why is this bad?

@@ -2103,7 +2120,7 @@

Past names

  • derive_hash_xor_eq
-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

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.

@@ -2124,7 +2141,6 @@

Example

use serde::Serialize;
 
-// Example code where clippy issues a warning
 println!("warns");
 
 // The diagnostic will contain the message "no serializing"
@@ -2160,8 +2176,7 @@ 
Example

     { path = "std::vec::Vec::leak", reason = "no leaking memory" },
 ]
-
// Example code where clippy issues a warning
-let xs = vec![1, 2, 3, 4];
+
let xs = vec![1, 2, 3, 4];
 xs.leak(); // Vec::leak is disallowed in the config.
 // The diagnostic contains the message "no leaking memory".
 
@@ -2170,8 +2185,7 @@ 
Example

 let _box = Box::new(3); // Box::new is disallowed in the config.
 

 
Use instead:

-
// Example code which does not raise clippy warning
-let mut xs = Vec::new(); // Vec::new is _not_ disallowed in the config.
+
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

@@ -2287,7 +2301,23 @@ 
Example

 let x = (a, b, c, panic!());
 // can simply be replaced by `panic!()`
 

-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

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"))]
+
+
Applicability: MachineApplicable(?)
Added in: 1.84.0
Related Issues
View Source

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 @@ -2323,7 +2353,7 @@

Example

/// * Then do something. Whatever it is needs done, /// it should be done right now. -
Applicability: MachineApplicable(?)
Added in: 1.80.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.63.0
Related Issues
View Source

What it does

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

Why is this bad?

@@ -2379,7 +2409,22 @@

Configuration

(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", "ClojureScript", "CoffeeScript", "JavaScript", "PostScript", "PureScript", "TypeScript", "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", "TeX", "LaTeX", "BibTeX", "BibLaTeX", "MinGW", "CamelCase"])

-
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

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)
+
+
Applicability: MaybeIncorrect(?)
Added in: 1.84.0
Related Issues
View Source

What it does

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

Why is this bad?

Readability.

@@ -2403,7 +2448,7 @@

Examples

unimplemented!(); } -
Applicability: Unspecified(?)
Added in: 1.40.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.40.0
Related Issues
View Source

What it does

Detects expressions of the form --x.

Why is this bad?

It can mislead C/C++ programmers to think x was @@ -2456,7 +2501,7 @@

Example

mem::take(v) } -
Applicability: MachineApplicable(?)
Added in: 1.72.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.72.0
Related Issues
View Source

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 @@ -2514,7 +2559,7 @@

Example

#[allow(dead_code)]
 fn foo() {}
-
Applicability: Unspecified(?)
Added in: 1.79.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.79.0
Related Issues
View Source

What it does

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

Why is this bad?

@@ -2603,7 +2648,7 @@

Example

true } -
Applicability: Unspecified(?)
Added in: 1.78.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.78.0
Related Issues
View Source

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 @@ -2711,7 +2756,7 @@

Example

fn new_code() {} -
Applicability: MaybeIncorrect(?)
Added in: 1.70.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.70.0
Related Issues
View Source

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 @@ -2734,7 +2779,7 @@

Example

#[allow(dead_code)] fn this_is_fine_too() {} -
Applicability: MaybeIncorrect(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for empty loop expressions.

Why is this bad?

These busy loops burn CPU cycles without doing @@ -3110,7 +3155,7 @@

Example

// .. } -
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

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

Why is this bad?

This unnecessarily complicates the code.

@@ -3122,7 +3167,7 @@

Example

let x = String::new();
 let y: &str = &x;
-
Applicability: MachineApplicable(?)
Added in: 1.64.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.64.0
Related Issues
View Source

What it does

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

Why is this bad?

@@ -3157,7 +3202,7 @@

Example

let _ = Foo::deref(&foo); let _ = <Foo as Deref>::deref(&foo); -
Applicability: MachineApplicable(?)
Added in: 1.44.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.44.0
Related Issues
View Source

What it does

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

Why is this bad?

@@ -3260,7 +3305,7 @@

Example

// ... } -
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

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 @@ -3390,7 +3435,7 @@

Example

Use instead:

_ = v.into_iter().filter(|i| i % 2 == 0).map(|i| really_expensive_fn(i));
-
Applicability: MachineApplicable(?)
Added in: 1.73.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.73.0
Related Issues
View Source

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.

@@ -3400,7 +3445,7 @@

Example

Use instead:

iter.flatten();
-
Applicability: MachineApplicable(?)
Added in: 1.52.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.52.0
Related Issues
View Source

What it does

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

Why is this bad?

Readability, this can be written more concisely as @@ -3578,21 +3623,7 @@

Example

(a - b).abs() < f32::EPSILON } -
Applicability: MaybeIncorrect(?)
Added in: 1.48.0
Related Issues
View Source

What it does

-

Checks for comparisons with an address of a function item.

-

Why is this bad?

-

Function item address is not guaranteed to be unique and could vary -between different code generation units. Furthermore different function items could have -the same address after being merged together.

-

Example

-
type F = fn();
-fn a() {}
-let f: F = a;
-if f == a {
-    // ...
-}
-
-
Applicability: Unspecified(?)
Added in: 1.44.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.48.0
Related Issues
View Source

What it does

Checks for excessive use of bools in function definitions.

Why is this bad?

@@ -3641,7 +3672,7 @@

Example

Use instead:

let _ = fun as usize;
-
Applicability: MaybeIncorrect(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: pre 1.29.0
Related Issues
View Source

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 @@ -3671,7 +3702,7 @@

Example

} let _ = fn3 as fn() -> u16; -
Applicability: MaybeIncorrect(?)
Added in: 1.58.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.58.0
Related Issues
View Source

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?

@@ -3692,7 +3723,7 @@

Example

let fn_ptr = fn1 as usize; let fn_ptr_truncated = fn_ptr as i32; -
Applicability: MaybeIncorrect(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

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

Why is this bad?

@@ -3741,7 +3772,7 @@

Example

}) } -
Applicability: Unspecified(?)
Added in: 1.73.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.73.0
Related Issues
View Source

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.

@@ -3818,7 +3849,7 @@

Example

instead of

let numbers = (1..=5).collect::<Vec<_>>();
-
Applicability: MaybeIncorrect(?)
Added in: 1.49.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.49.0
Related Issues
View Source

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.

@@ -3879,9 +3910,14 @@

Example

Applicability: MaybeIncorrect(?)
Added in: 1.52.0
Related Issues
View Source

What it does

This lint requires Future implementations returned from -functions and methods to implement the Send marker trait. It is mostly -used by library authors (public and internal) that target an audience where -multithreaded executors are likely to be used for running these Futures.

+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 @@ -3901,7 +3937,7 @@

Example

Use instead:

async fn is_send(bytes: std::sync::Arc<[u8]>) {}
-
Applicability: Unspecified(?)
Added in: 1.44.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.44.0
Related Issues
View Source

What it does

Checks for usage of x.get(0) instead of x.first() or x.front().

Why is this bad?

@@ -3915,7 +3951,7 @@

Example

let x = vec![2, 3, 5];
 let first_element = x.first();
-
Applicability: MachineApplicable(?)
Added in: 1.63.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.63.0
Related Issues
View Source

What it does

Checks for usage of x.get(x.len() - 1) instead of x.last().

Why is this bad?

@@ -3979,6 +4015,11 @@

Example

Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

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.

@@ -3997,7 +4038,7 @@

Example

use_locked(locked); } -
Applicability: Unspecified(?)
Added in: 1.45.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.45.0
Related Issues
View Source

What it does

Checks for usage of ! or != in an if condition with an else branch.

Why is this bad?

@@ -4016,7 +4057,7 @@

Example

a() } -
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for if/else with the same body as the then part and the else part.

Why is this bad?

@@ -4162,7 +4203,7 @@

Example

// [...] } -
Applicability: HasPlaceholders(?)
Added in: 1.69.0
Related Issues
View Source

What it does

+
Applicability: HasPlaceholders(?)
Added in: 1.69.0
Related Issues
View Source

What it does

Checks for the usage of _.to_owned(), vec.to_vec(), or similar when calling _.clone() would be clearer.

Why is this bad?

These methods do the same thing as _.clone() but may be confusing as @@ -4177,7 +4218,7 @@

Example

let b = a.clone(); let c = a.clone(); -
Applicability: MachineApplicable(?)
Added in: 1.52.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.52.0
Related Issues
View Source

What it does

Checks for public impl or fn missing generalization over different hashers and implicitly defaulting to the default hashing algorithm (SipHash).

@@ -4395,36 +4436,48 @@

Configuration

Applicability: MaybeIncorrect(?)
Added in: 1.59.0
Related Issues
View Source

What it does

-

Checks for usage of indexing or slicing. Arrays are special cases, this lint -does report on arrays if we can tell that slicing operations are in bounds and does not -lint on constant usize indexing on arrays because that is handled by rustc’s const_err lint.

+

Checks for usage of indexing or slicing that may panic at runtime.

+

This lint does not report on indexing or slicing operations +that always panic, clippy’s out_of_bound_indexing already +handles those cases.

Why restrict this?

-

To avoid implicit panics from indexing and slicing. -There are “checked” alternatives which do not panic, and can be used with unwrap() to make +

To avoid implicit panics from indexing and slicing.

+

There are “checked” alternatives which do not panic, and can be used with unwrap() to make an explicit panic when it is desired.

+

Limitations

+

This lint does not check for the usage of indexing or slicing on strings. These are covered +by the more specific string_slice lint.

Example

// Vector
-let x = vec![0; 5];
+let x = vec![0, 1, 2, 3];
 
 x[2];
+x[100];
 &x[2..100];
 
 // Array
 let y = [0, 1, 2, 3];
 
-&y[10..100];
-&y[10..];
+let i = 10; // Could be a runtime value
+let j = 20;
+&y[i..j];

Use instead:

x.get(2);
+x.get(100);
 x.get(2..100);
 
-y.get(10);
-y.get(10..100);
+let i = 10;
+let j = 20;
+y.get(i..j);

Configuration

  • +

    allow-indexing-slicing-in-tests: Whether indexing_slicing should be allowed in test functions or #[cfg(test)]

    +

    (default: false)

    +
    • +

  • suppress-restriction-lint-in-const: Whether to suppress a restriction lint in constant code. In same cases the restructured operation might not be unavoidable, as the suggested counterparts are unavailable in constant code. This @@ -4513,7 +4566,7 @@

    Example

    let wrapper = Wrapper::Data(42); let Wrapper::Data(data) = wrapper; -
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for iteration that is guaranteed to be infinite.

Why is this bad?

While there may be places where this is acceptable @@ -4648,7 +4701,7 @@

Example

#[inline(always)]
 fn not_quite_hot_code(..) { ... }
-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for usage of AT&T x86 assembly syntax.

Why restrict this?

To enforce consistent use of Intel x86 assembly syntax.

@@ -4698,7 +4751,7 @@

Example

assert!(x >= 0); }); -
Applicability: Unspecified(?)
Added in: 1.51.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.51.0
Related Issues
View Source

What it does

Checks for usage of x >= y + 1 or x - 1 >= y (and <=) in a block

Why is this bad?

Readability – better to use > y instead of >= y + 1.

@@ -4865,7 +4918,7 @@

Example

c.is_ascii_digit(); c.is_ascii_hexdigit(); -
Applicability: MachineApplicable(?)
Added in: 1.62.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.62.0
Related Issues
View Source

What it does

Checks for items declared after some statement in a block.

Why is this bad?

Items live for the entire scope they are declared @@ -4951,37 +5004,33 @@

Example

some_vec.len(); &some_vec[..].len(); -
Applicability: MachineApplicable(?)
Added in: 1.52.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.52.0
Related Issues
View Source

What it does

Checks for usage of .filter(Result::is_ok) that may be replaced with a .flatten() call. This lint will require additional changes to the follow-up calls as it affects the type.

Why is this bad?

This pattern is often followed by manual unwrapping of Result. The simplification results in more readable and succinct code without the need for manual unwrapping.

Example

-
// example code where clippy issues a warning
-vec![Ok::<i32, String>(1)].into_iter().filter(Result::is_ok);
+
vec![Ok::<i32, String>(1)].into_iter().filter(Result::is_ok);
 
 

 
Use instead:

-
// example code which does not raise clippy warning
-vec![Ok::<i32, String>(1)].into_iter().flatten();
+
vec![Ok::<i32, String>(1)].into_iter().flatten();
 

-
Applicability: HasPlaceholders(?)
Added in: 1.77.0
Related Issues
View Source

What it does

+
Applicability: HasPlaceholders(?)
Added in: 1.77.0
Related Issues
View Source

What it does

Checks for usage of .filter(Option::is_some) that may be replaced with a .flatten() call. This lint will require additional changes to the follow-up calls as it affects the type.

Why is this bad?

This pattern is often followed by manual unwrapping of the Option. The simplification results in more readable and succinct code without the need for manual unwrapping.

Example

-
// example code where clippy issues a warning
-vec![Some(1)].into_iter().filter(Option::is_some);
+
vec![Some(1)].into_iter().filter(Option::is_some);
 
 

 
Use instead:

-
// example code which does not raise clippy warning
-vec![Some(1)].into_iter().flatten();
+
vec![Some(1)].into_iter().flatten();
 

-
Applicability: HasPlaceholders(?)
Added in: 1.77.0
Related Issues
View Source

What it does

+
Applicability: HasPlaceholders(?)
Added in: 1.77.0
Related Issues
View Source

What it does

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

Why is this bad?

@@ -5002,7 +5051,7 @@

Configuration

(default: current version)

-
Applicability: MachineApplicable(?)
Added in: 1.66.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.66.0
Related Issues
View Source

What it does

Checks for loops on x.next().

Why is this bad?

next() returns either Some(value) if there was a @@ -5093,7 +5142,7 @@

Example

Known problems

The type of the resulting iterator might become incompatible with its usage

-
Applicability: MaybeIncorrect(?)
Added in: 1.65.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.65.0
Related Issues
View Source

What it does

Checks for calls to iter, iter_mut or into_iter on collections containing a single item

Why is this bad?

It is simpler to use the once function from the standard library:

@@ -5108,7 +5157,7 @@

Example

Known problems

The type of the resulting iterator might become incompatible with its usage

-
Applicability: MaybeIncorrect(?)
Added in: 1.65.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.65.0
Related Issues
View Source

What it does

Looks for iterator combinator calls such as .take(x) or .skip(x) where x is greater than the amount of items that an iterator will produce.

Why is this bad?

@@ -5121,7 +5170,7 @@

Example

Use instead:

for _ in [1, 2, 3].iter() {}
-
Applicability: Unspecified(?)
Added in: 1.74.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.74.0
Related Issues
View Source

What it does

This is a restriction lint which prevents the use of hash types (i.e., HashSet and HashMap) in for loops.

Why restrict this?

Because hash types are unordered, when iterated through such as in a for loop, the values are returned in @@ -5181,7 +5230,7 @@

Example

let y = v.iter().collect::<Vec<_>>(); assert_eq!(x, y); -
Applicability: MaybeIncorrect(?)
Added in: 1.73.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.73.0
Related Issues
View Source

What it does

Checks for usage of .drain(..) on Vec and VecDeque for iteration.

Why is this bad?

.into_iter() is simpler with better performance.

@@ -5259,7 +5308,7 @@

Example

let new = Path::new("/sh"); assert_eq!(new, PathBuf::from("/sh")); -
Applicability: Unspecified(?)
Added in: 1.76.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.76.0
Related Issues
View Source

What it does

Checks if you have variables whose name consists of just underscores and digits.

Why is this bad?

@@ -5750,7 +5799,22 @@

Example

pedantic = { level = "warn", priority = -1 } similar_names = "allow" -
Applicability: Unspecified(?)
Added in: 1.78.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.78.0
Related Issues
View Source

What it does

+

Checks if string literals have formatting arguments outside of macros +using them (like format!).

+

Why is this bad?

+

It will likely not generate the expected content.

+

Example

+
let x: Option<usize> = None;
+let y = "hello";
+x.expect("{y:?}");
+
+

Use instead:

+
let x: Option<usize> = None;
+let y = "hello";
+x.expect(&format!("{y:?}"));
+
+
Applicability: Unspecified(?)
Added in: 1.83.0
Related Issues
View Source

What it does

Checks for the usage of the to_le_bytes method and/or the function from_le_bytes.

Why restrict this?

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

@@ -5843,7 +5907,7 @@

Example

#[macro_use]
 use some_macro;
-
Applicability: MaybeIncorrect(?)
Added in: 1.44.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.44.0
Related Issues
View Source

What it does

Checks for recursion using the entrypoint.

Why is this bad?

Apart from special setups (which we could detect following attributes like #![no_std]), @@ -5923,7 +5987,7 @@

Configuration

(default: current version)

-
Applicability: MachineApplicable(?)
Added in: 1.78.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.78.0
Related Issues
View Source

What it does

Identifies good opportunities for a clamp function from std or core, and suggests using it.

Why is this bad?

clamp is much shorter, easier to read, and doesn’t use any control flow.

@@ -5985,7 +6049,7 @@

Example

let y: i32 = 4; let div = x.div_ceil(y); -
Applicability: MachineApplicable(?)
Added in: 1.81.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.83.0
Related Issues
View Source

What it does

Checks for usage of match which could be implemented using filter

Why is this bad?

Using the filter method is clearer and more concise.

@@ -6002,7 +6066,7 @@

Example

Use instead:

Some(0).filter(|&x| x % 2 == 0);
-
Applicability: MachineApplicable(?)
Added in: 1.66.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.66.0
Related Issues
View Source

What it does

Checks for usage of _.filter(_).map(_) that can be written more simply as filter_map(_).

Why is this bad?

@@ -6133,7 +6197,7 @@

Example

Use instead:

let x = Some(0).inspect(|x| println!("{x}"));
-
Applicability: MachineApplicable(?)
Added in: 1.81.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.81.0
Related Issues
View Source

What it does

Lints subtraction between Instant::now() and another Instant.

Why is this bad?

It is easy to accidentally write prev_instant - Instant::now(), which will always be 0ns @@ -6203,7 +6267,7 @@

Example

if x.is_finite() {}
 if x.is_finite() {}
-
Applicability: MaybeIncorrect(?)
Added in: 1.73.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.73.0
Related Issues
View Source

What it does

Checks for manual is_infinite reimplementations (i.e., x == <float>::INFINITY || x == <float>::NEG_INFINITY).

Why is this bad?

@@ -6214,7 +6278,7 @@

Example

Use instead:

if x.is_infinite() {}
-
Applicability: MachineApplicable(?)
Added in: 1.73.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.73.0
Related Issues
View Source

What it does

Checks for expressions like x.count_ones() == 1 or x & (x - 1) == 0, with x and unsigned integer, which may be manual reimplementations of x.is_power_of_two().

Why is this bad?

@@ -6227,7 +6291,7 @@

Example

let a: u32 = 4;
 let result = a.is_power_of_two();
-
Applicability: MachineApplicable(?)
Added in: 1.82.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.83.0
Related Issues
View Source

What it does

Checks for usage of option.map(f).unwrap_or_default() and result.map(f).unwrap_or_default() where f is a function or closure that returns the bool type.

Why is this bad?

Readability. These can be written more concisely as option.is_some_and(f) and result.is_ok_and(f).

@@ -6239,7 +6303,7 @@

Example

option.is_some_and(|a| a > 10);
 result.is_ok_and(|a| a > 10);
-
Applicability: MachineApplicable(?)
Added in: 1.77.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.77.0
Related Issues
View Source

What it does

Warn of cases where let...else could be used

Why is this bad?

let...else provides a standard construct for this pattern @@ -6262,7 +6326,7 @@

Configuration

(default: current version)

-
Applicability: HasPlaceholders(?)
Added in: 1.67.0
Related Issues
View Source

What it does

+
Applicability: HasPlaceholders(?)
Added in: 1.67.0
Related Issues
View Source

What it does

Checks for references on std::path::MAIN_SEPARATOR.to_string() used to build a &str.

Why is this bad?

@@ -6287,7 +6351,7 @@

Example

Use instead:

Some(0).map(|x| x + 1);
-
Applicability: MachineApplicable(?)
Added in: 1.52.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.52.0
Related Issues
View Source

What it does

Checks for for-loops that manually copy items between slices that could be optimized by having a memcpy.

Why is this bad?

@@ -6310,7 +6374,7 @@

Example

Use instead:

foo.iter().next_back();
-
Applicability: MachineApplicable(?)
Added in: 1.71.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.71.0
Related Issues
View Source

What it does

Checks for manual implementations of the non-exhaustive pattern.

Why is this bad?

Using the #[non_exhaustive] attribute expresses better the intent @@ -6366,7 +6430,7 @@

Examples

let foo: Option<i32> = None;
 foo.ok_or("error");
-
Applicability: MachineApplicable(?)
Added in: 1.49.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.49.0
Related Issues
View Source

What it does

Checks for manual char comparison in string patterns

Why is this bad?

This can be written more concisely using a char or an array of char. @@ -6538,7 +6602,7 @@

Configuration

(default: current version)

-
Applicability: MachineApplicable(?)
Added in: 1.57.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.57.0
Related Issues
View Source

What it does

Checks for manual implementations of str::repeat

Why is this bad?

These are both harder to read, as well as less performant.

@@ -6555,7 +6619,7 @@

Configuration

(default: current version)

-
Applicability: MachineApplicable(?)
Added in: 1.54.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.54.0
Related Issues
View Source

What it does

Checks for usage of "" to create a String, such as "".to_string(), "".to_owned(), String::from("") and others.

Why is this bad?

@@ -6639,7 +6703,7 @@

Configuration

(default: current version)

-
Applicability: HasPlaceholders(?)
Added in: 1.72.0
Related Issues
View Source

What it does

+
Applicability: HasPlaceholders(?)
Added in: 1.72.0
Related Issues
View Source

What it does

Finds patterns that reimplement Option::unwrap_or or Result::unwrap_or.

Why is this bad?

Concise code helps focusing on behavior instead of boilerplate.

@@ -6654,7 +6718,7 @@

Example

let foo: Option<i32> = None;
 foo.unwrap_or(1);
-
Applicability: MachineApplicable(?)
Added in: 1.49.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.49.0
Related Issues
View Source

What it does

Checks if a match or if let expression can be simplified using .unwrap_or_default().

Why is this bad?

@@ -6727,7 +6791,7 @@

Example

let e1 = v.iter().all(|s| s.is_empty());
 let e2 = v.iter().any(|s| s.is_empty());
-
Applicability: MachineApplicable(?)
Added in: 1.84.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.84.0
Related Issues
View Source

What it does

Checks for usage of map(|x| x.clone()) or dereferencing closures for Copy types, on Iterator or Option, and suggests cloned() or copied() instead

@@ -6750,7 +6814,7 @@

Configuration

(default: current version)

-
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for usage of _.map(_).collect::<Result<(), _>().

Why is this bad?

Using try_for_each instead is more readable and idiomatic.

@@ -6760,7 +6824,7 @@

Example

Use instead:

(0..3).try_for_each(|t| Err(t));
-
Applicability: MachineApplicable(?)
Added in: 1.49.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.49.0
Related Issues
View Source

What it does

Checks for usage of contains_key + insert on HashMap or BTreeMap.

Why is this bad?

@@ -6871,7 +6935,7 @@

Example

}) } -
Applicability: Unspecified(?)
Added in: 1.48.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.48.0
Related Issues
View Source

What it does

Checks for usage of _.map(_).flatten(_) on Iterator and Option

Why is this bad?

Readability, this can be written more concisely as @@ -6899,7 +6963,7 @@

Example

let x = [1, 2, 3];
 let y: Vec<_> = x.iter().map(|x| 2*x).collect();
-
Applicability: MachineApplicable(?)
Added in: 1.47.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.47.0
Related Issues
View Source

What it does

Checks for usage of option.map(_).unwrap_or(_) or option.map(_).unwrap_or_else(_) or result.map(_).unwrap_or_else(_).

Why is this bad?

@@ -6955,7 +7019,7 @@

Configuration

(default: current version)

-
Applicability: MaybeIncorrect(?)
Added in: 1.84.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.84.0
Related Issues
View Source

What it does

Checks for match which is used to add a reference to an Option value.

Why is this bad?

@@ -6973,7 +7037,7 @@

Example

let r: Option<&()> = x.as_ref(); -
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for matches where match expression is a bool. It suggests to replace the expression with an if...else block.

Why is this bad?

@@ -6993,7 +7057,7 @@

Example

bar(); } -
Applicability: HasPlaceholders(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: HasPlaceholders(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for match or if let expressions producing a bool that could be written using matches!

Why is this bad?

@@ -7026,7 +7090,7 @@

Configuration

(default: current version)

-
Applicability: MaybeIncorrect(?)
Added in: 1.47.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.47.0
Related Issues
View Source

What it does

Checks for match vec[idx] or match vec[n..m].

Why is this bad?

This can panic at runtime.

@@ -7050,7 +7114,7 @@

Example

_ => {}, } -
Applicability: MaybeIncorrect(?)
Added in: 1.45.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.45.0
Related Issues
View Source

What it does

Checks for overlapping match arms.

Why is this bad?

It is likely to be an error and if not, makes the code @@ -7063,7 +7127,7 @@

Example

_ => (), } -
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for matches where all arms match a reference, suggesting to remove the reference and deref the matched expression instead. It also checks for if let &foo = bar blocks.

@@ -7084,7 +7148,7 @@

Example

_ => frob(x), } -
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for unnecessary ok() in while let.

Why is this bad?

Calling ok() in while let is unnecessary, instead match @@ -7143,7 +7207,7 @@

Example

Quz => quz(), } -
Applicability: MaybeIncorrect(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for useless match that binds to only one value.

Why is this bad?

Readability and needless complexity.

@@ -7160,7 +7224,7 @@

Example

Use instead:

let (c, d) = (a, b);
-
Applicability: MachineApplicable(?)
Added in: 1.43.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.43.0
Related Issues
View Source

What it does

Checks for match expressions modifying the case of a string with non-compliant arms

Why is this bad?

The arm is unreachable, which is likely a mistake

@@ -7178,7 +7242,7 @@

Example

_ => {}, } -
Applicability: MachineApplicable(?)
Added in: 1.58.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.58.0
Related Issues
View Source

What it does

Checks for arm which matches all errors with Err(_) and take drastic actions like panic!.

Why is this bad?

@@ -7191,7 +7255,7 @@

Example

Err(_) => panic!("err"), } -
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for wildcard enum matches for a single variant.

Why is this bad?

New enum variants added by library updates can be missed.

@@ -7212,7 +7276,7 @@

Example

Foo::C => {}, } -
Applicability: MaybeIncorrect(?)
Added in: 1.45.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.45.0
Related Issues
View Source

What it does

Checks for iteration that may be infinite.

Why is this bad?

While there may be places where this is acceptable @@ -7397,7 +7461,7 @@

Example

} } -
Applicability: MaybeIncorrect(?)
Added in: 1.67.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.67.0
Related Issues
View Source

What it does

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

Why is this bad?

Most likely these are bugs where one meant to write a op= b.

@@ -7519,14 +7583,12 @@

Why is this bad?

does not need to track any additional state.

https://doc.rust-lang.org/std/macro.thread_local.html

Example

-
// example code where clippy issues a warning
-thread_local! {
+
thread_local! {
     static BUF: String = String::new();
 }
 

 
Use instead:

-
// example code which does not raise clippy warning
-thread_local! {
+
thread_local! {
     static BUF: String = const { String::new() };
 }
 

@@ -7549,7 +7611,7 @@ 
Configuration

 
(default: false)

 
 
-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for imports that do not rename the item as specified in the enforced-import-renames config option.

Note: Even though this lint is warn-by-default, it will only trigger if @@ -7600,7 +7662,7 @@

Configuration

(default: false)

-
Applicability: Unspecified(?)
Added in: 1.41.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.41.0
Related Issues
View Source

What it does

Checks for manual core::fmt::Debug implementations that do not use all fields.

Why is this bad?

A common mistake is to forget to update manual Debug implementations when adding a new field @@ -7720,7 +7782,7 @@

Configuration

(default: false)

-
Applicability: Unspecified(?)
Added in: 1.51.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.51.0
Related Issues
View Source

What it does

Checks for the doc comments of publicly visible unsafe functions and warns if there is no # Safety section.

Why is this bad?

@@ -7747,7 +7809,7 @@

Configuration

(default: false)

-
Applicability: Unspecified(?)
Added in: 1.39.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.39.0
Related Issues
View Source

What it does

Checks for empty spin loops

Why is this bad?

The loop body should have something like thread::park() or at least @@ -7874,7 +7936,7 @@

Example

pub fn foo() { } -
Applicability: Unspecified(?)
Added in: 1.78.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.78.0
Related Issues
View Source

What it does

Warns on hexadecimal literals with mixed-case letter digits.

Why is this bad?

@@ -8179,7 +8241,7 @@

Examples

// this could be annotated with `#[must_use]`.
 pub fn id<T>(t: T) -> T { t }
-
Applicability: MachineApplicable(?)
Added in: 1.40.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.40.0
Related Issues
View Source

What it does

Checks for a #[must_use] attribute on unit-returning functions and methods.

Why is this bad?

@@ -8189,7 +8251,7 @@

Examples

#[must_use]
 fn useless() { }
-
Applicability: MachineApplicable(?)
Added in: 1.40.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.40.0
Related Issues
View Source

What it does

This lint checks for functions that take immutable references and return mutable ones. This will not trigger if no unsafe code exists as there are multiple safe functions which will do this transformation

@@ -8243,7 +8305,7 @@

Example

let value = value_mutex.get_mut().unwrap(); *value += 1; -
Applicability: MaybeIncorrect(?)
Added in: 1.49.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.49.0
Related Issues
View Source

What it does

Checks for loops with a range bound that is a mutable variable.

Why is this bad?

One might think that modifying the mutable variable changes the loop bounds. It doesn’t.

@@ -8364,7 +8426,7 @@

Example

Use instead:

let count = bytecount::count(&vec, 0u8);
-
Applicability: MaybeIncorrect(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

The lint checks for self in fn parameters that specify the Self-type explicitly

Why is this bad?

@@ -8417,7 +8479,7 @@

Example

let len = "some string".len();
 let b = "some string".is_empty();
-
Applicability: MachineApplicable(?)
Added in: 1.84.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.84.0
Related Issues
View Source

What it does

Checks for usage of bitwise and/or operators between booleans, where performance may be improved by using a lazy and.

Why is this bad?

@@ -8500,7 +8562,7 @@

Configuration

(default: current version)

-
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for bindings that needlessly destructure a reference and borrow the inner value with &ref.

Why is this bad?

@@ -8549,7 +8611,7 @@

Example

Use instead:

"foo".is_ascii();
-
Applicability: MachineApplicable(?)
Added in: 1.81.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.81.0
Related Issues
View Source

What it does

Checks for functions collecting an iterator when collect is not needed.

Why is this bad?

@@ -8561,7 +8623,7 @@

Example

Use instead:

let len = iterator.count();
-
Applicability: MachineApplicable(?)
Added in: 1.30.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.30.0
Related Issues
View Source

What it does

The lint checks for if-statements appearing in loops that contain a continue statement in either their main blocks or their else-blocks, when omitting the else-block possibly with some @@ -8630,7 +8692,7 @@

Examples

unimplemented!(); } -
Applicability: Unspecified(?)
Added in: 1.40.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.40.0
Related Issues
View Source

What it does

Checks for empty else branches.

Why is this bad?

An empty else branch does nothing and can be removed.

@@ -8749,7 +8811,7 @@

Example

x } -
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for unnecessary match or match-like if let returns for Option and Result when function signatures are the same.

Why is this bad?

@@ -8779,7 +8841,7 @@

Example

option } -
Applicability: MachineApplicable(?)
Added in: 1.61.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.61.0
Related Issues
View Source

What it does

Lints ?Sized bounds applied to type parameters that cannot be unsized

Why is this bad?

The ?Sized bound is misleading because it cannot be satisfied by an @@ -8806,7 +8868,7 @@

Example

let a = Some(&1);
 let b = a;
-
Applicability: MachineApplicable(?)
Added in: 1.57.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.57.0
Related Issues
View Source

What it does

Checks for calling take function after as_ref.

Why is this bad?

Redundant code. take writes None to its argument. @@ -8819,7 +8881,7 @@

Example

let x = Some(3);
 x.as_ref();
-
Applicability: MachineApplicable(?)
Added in: 1.62.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.62.0
Related Issues
View Source

What it does

The lint checks for parenthesis on literals in range statements that are superfluous.

Why is this bad?

@@ -8883,7 +8945,7 @@

Example

assert_eq!(v.len(), 42); } -
Applicability: MaybeIncorrect(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for usage of pub(self) and pub(in self).

Why is this bad?

It’s unnecessary, omitting the pub entirely will give the same results.

@@ -9032,7 +9094,7 @@

Example

let str = "key=value=add";
 let _ = str.split('=').next().unwrap();
-
Applicability: MachineApplicable(?)
Added in: 1.59.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.59.0
Related Issues
View Source

What it does

Checks for needlessly including a base struct on update when all fields are changed anyway.

This lint is not applied to structs marked with @@ -9202,7 +9264,7 @@

Example

"1234".replace("12", "12");
 "1234".replacen("12", "12", 1);
-
Applicability: Unspecified(?)
Added in: 1.63.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.63.0
Related Issues
View Source

What it does

Checks for binding to underscore prefixed variable without side-effects.

Why is this bad?

Unlike dead code, these bindings are actually @@ -9331,7 +9393,7 @@

Example

#[cfg(unix)]
 pub struct Bar;
-
Applicability: MaybeIncorrect(?)
Added in: 1.71.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.71.0
Related Issues
View Source

What it does

Checks for non-octal values used to set Unix file permissions.

Why is this bad?

They will be converted into octal, creating potentially @@ -9416,7 +9478,7 @@

Example

let r2 = x % NonZeroU64::from(y); } -
Applicability: MachineApplicable(?)
Added in: 1.81.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.83.0
Related Issues
View Source

What it does

Checks for boolean expressions that can be written more concisely.

Why is this bad?

@@ -9433,7 +9495,7 @@

Example

if a {}
 if a != b {}
-
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for duplicate open options as well as combinations that make no sense.

Why is this bad?

@@ -9444,7 +9506,7 @@

Example

OpenOptions::new().read(true).truncate(true); -
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks that common macros are used with consistent bracing.

Why is this bad?

This is mostly a consistency lint although using () or [] @@ -9510,7 +9572,7 @@

Example

// sound call if the caller knows the pointer is valid unsafe { foo(valid_ptr); } -
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for usage of .then_some(..).unwrap_or(..)

Why is this bad?

This can be written more clearly with if .. else ..

@@ -9526,7 +9588,7 @@

Example

let x = true;
 if x { "a" } else { "b" };
-
Applicability: MachineApplicable(?)
Added in: 1.64.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.64.0
Related Issues
View Source

What it does

Checks for \0 escapes in string and byte literals that look like octal character escapes in C.

Why is this bad?

@@ -9638,7 +9700,7 @@

Example

bar.clone() } -
Applicability: MachineApplicable(?)
Added in: 1.77.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.77.0
Related Issues
View Source

What it does

Checks for usage of _.as_ref().map(Deref::deref) or its aliases (such as String::as_str).

Why is this bad?

Readability, this can be written more concisely as @@ -9731,7 +9793,7 @@

Example

Use instead:

opt.ok_or("error");
-
Applicability: MachineApplicable(?)
Added in: 1.76.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.76.0
Related Issues
View Source

What it does

Checks for usage of _.map_or(None, _).

Why is this bad?

Readability, this can be written more concisely as @@ -9869,7 +9931,7 @@

Past names

  • logic_bug
-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for usage of panic!.

Why restrict this?

This macro, or panics in general, may be unwanted in production code.

@@ -10017,7 +10079,7 @@

Example

x.push("bar"); assert_eq!(x, PathBuf::from("/foo/bar")); -
Applicability: MachineApplicable(?)
Added in: 1.36.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.36.0
Related Issues
View Source

What it does

Looks for calls to Path::ends_with calls where the argument looks like a file extension.

By default, Clippy has a short list of known filenames that start with a dot but aren’t necessarily file extensions (e.g. the .git folder), which are allowed by default. @@ -10048,7 +10110,7 @@

Configuration

(default: [])

-
Applicability: MaybeIncorrect(?)
Added in: 1.74.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.74.0
Related Issues
View Source

What it does

Checks for calls to push immediately after creating a new PathBuf.

Why is this bad?

Multiple .join() calls are usually easier to read than multiple .push @@ -10164,6 +10226,7 @@

Example

  • mixed usage of arithmetic and bit shifting/combining operators without parentheses
    • +
  • mixed usage of bitmasking and bit shifting operators without parentheses

Why is this bad?

Not everyone knows the precedence of those operators by @@ -10172,8 +10235,9 @@

Why is this bad?

Example

  • 1 << 2 + 3 equals 32, while (1 << 2) + 3 equals 7
    • +
  • 0x2345 & 0xF000 >> 12 equals 5, while (0x2345 & 0xF000) >> 12 equals 2
-
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.51.0
Related Issues
View Source

What it does

Checks for as casts between raw pointers that change their constness, namely *const T to *mut T and *mut T to *const T.

Why is this bad?

@@ -10347,7 +10411,7 @@

Example

let ptr3 = std::ptr::null_mut::<u32>(); let ptr4 = std::ptr::null::<u32>(); -
Applicability: MachineApplicable(?)
Added in: 1.72.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.72.0
Related Issues
View Source

What it does

Use std::ptr::eq when applicable

Why is this bad?

ptr::eq can be used to compare &T references @@ -10556,7 +10620,7 @@

Example

Use instead:

let _ = x.iter().enumerate();
-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for Rc<T> and Arc<T> when T is a mutable buffer type such as String or Vec.

Why restrict this?

Expressions such as Rc<String> usually have no advantage over Rc<str>, since @@ -10653,7 +10717,7 @@

Example

// ^^^^^^^^^^^ remove the trailing newline assert_eq!(num, 42); -
Applicability: MachineApplicable(?)
Added in: 1.73.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.73.0
Related Issues
View Source

What it does

This lint catches reads into a zero-length Vec. Especially in the case of a call to with_capacity, this lint warns that read gets the number of bytes from the Vec’s length, not its capacity.

@@ -10697,7 +10761,7 @@

Example

assert_eq!(*num, 0); } -
Applicability: MaybeIncorrect(?)
Added in: 1.73.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.73.0
Related Issues
View Source

What it does

Checks for format trait implementations (e.g. Display) with a recursive call to itself which uses self as a parameter. This is typically done indirectly with the write! macro or with to_string().

@@ -10758,7 +10822,7 @@

Example

let owned_string = "This is a string".to_owned();
 owned_string.as_bytes()
-
Applicability: MachineApplicable(?)
Added in: 1.74.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.74.0
Related Issues
View Source

What it does

Checks for async block that only returns await on a future.

Why is this bad?

It is simpler and more efficient to use the future directly.

@@ -10952,7 +11016,7 @@

Example

_ => todo!(), } -
Applicability: MaybeIncorrect(?)
Added in: 1.73.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.73.0
Related Issues
View Source

What it does

Checks for redundant redefinitions of local bindings.

Why is this bad?

Redundant redefinitions of local bindings do not change behavior and are likely to be unintended.

@@ -11040,7 +11104,7 @@

Past names

  • if_let_redundant_pattern_matching
-
Applicability: MachineApplicable(?)
Added in: 1.31.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.31.0
Related Issues
View Source

What it does

Checks for items declared pub(crate) that are not crate visible because they are inside a private module.

Why is this bad?

@@ -11134,7 +11198,7 @@

Example

let a_ref = &1;
 let a_ptr = std::ptr::from_ref(a_ref);
-
Applicability: MachineApplicable(?)
Added in: 1.78.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.78.0
Related Issues
View Source

What it does

Checks for ref bindings which create a reference to a reference.

Why is this bad?

The address-of operator at the use site is clearer about the need for a reference.

@@ -11150,7 +11214,7 @@

Example

// use `&x` here } -
Applicability: MachineApplicable(?)
Added in: 1.54.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.54.0
Related Issues
View Source

What it does

Warns when a function signature uses &Option<T> instead of Option<&T>.

Why is this bad?

More flexibility, better memory optimization, and more idiomatic Rust code.

@@ -11184,7 +11248,7 @@

Configuration

(default: true)

-
Applicability: Unspecified(?)
Added in: 1.83.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.83.0
Related Issues
View Source

What it does

Checks for usage of &Option<&T>.

Why is this bad?

Since & is Copy, it’s useless to have a @@ -11277,7 +11341,7 @@

Noteworthy

(default: ["core::convert::From", "core::convert::TryFrom", "core::str::FromStr"])

-
Applicability: Unspecified(?)
Added in: 1.80.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.80.0
Related Issues
View Source

What it does

Checks for usage of .repeat(1) and suggest the following method for each types.

  • .to_string() for str
    • @@ -11299,7 +11363,7 @@

    Example

    let x = String::from("hello world").clone(); } -
Applicability: MachineApplicable(?)
Added in: 1.47.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.47.0
Related Issues
View Source

What it does

Looks for patterns such as vec![Vec::with_capacity(x); n] or iter::repeat(Vec::with_capacity(x)).

Why is this bad?

These constructs work by cloning the element, but cloning a Vec<_> does not @@ -11326,7 +11390,32 @@

Example

Nothing. This lint has been deprecated

Deprecation reason

min_value and max_value are now deprecated.

-
Applicability: Unspecified(?)
Deprecated in: 1.44.0
Related Issues

What it does

+
Applicability: Unspecified(?)
Deprecated in: 1.44.0
Related Issues

What it does

+

Checks for items with #[repr(packed)]-attribute without ABI qualification

+

Why is this bad?

+

Without qualification, repr(packed) implies repr(Rust). The Rust-ABI is inherently unstable. +While this is fine as long as the type is accessed correctly within Rust-code, most uses +of #[repr(packed)] involve FFI and/or data structures specified by network-protocols or +other external specifications. In such situations, the unstable Rust-ABI implied in +#[repr(packed)] may lead to future bugs should the Rust-ABI change.

+

In case you are relying on a well defined and stable memory layout, qualify the type’s +representation using the C-ABI. Otherwise, if the type in question is only ever +accessed from Rust-code according to Rust’s rules, use the Rust-ABI explicitly.

+

Example

+
#[repr(packed)]
+struct NetworkPacketHeader {
+    header_length: u8,
+    header_version: u16
+}
+
+

Use instead:

+
#[repr(C, packed)]
+struct NetworkPacketHeader {
+    header_length: u8,
+    header_version: u16
+}
+
+
Applicability: Unspecified(?)
Added in: 1.84.0
Related Issues
View Source

What it does

Informs the user about a more concise way to create a vector with a known capacity.

Why is this bad?

The Vec::with_capacity constructor is less complex.

@@ -11356,7 +11445,7 @@

Example

_ => {}, } -
Applicability: Unspecified(?)
Added in: 1.43.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.43.0
Related Issues
View Source

What it does

Checks for iterators of Results using .filter(Result::is_ok).map(Result::unwrap) that may be replaced with a .flatten() call.

Why is this bad?

@@ -11368,7 +11457,7 @@

Example

Use instead:

let _ = std::iter::empty::<Result<i32, ()>>().flatten();
-
Applicability: MachineApplicable(?)
Added in: 1.77.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.77.0
Related Issues
View Source

What it does

Checks for functions that return Result with an unusually large Err-variant.

Why is this bad?

@@ -11411,7 +11500,7 @@

Configuration

(default: 128)

-
Applicability: Unspecified(?)
Added in: 1.65.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.65.0
Related Issues
View Source

What it does

Checks for usage of _.map_or(None, Some).

Why is this bad?

Readability, this can be written more concisely as @@ -11476,7 +11565,7 @@

Examples

Note that there are crates that simplify creating the error type, e.g. thiserror.

-
Applicability: Unspecified(?)
Added in: 1.49.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.49.0
Related Issues
View Source

What it does

This lint warns when a method returning Self doesn’t have the #[must_use] attribute.

Why is this bad?

Methods returning Self often create new values, having the #[must_use] attribute @@ -11675,7 +11764,7 @@

Configuration

(default: current version)

-
Applicability: MachineApplicable(?)
Added in: 1.67.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.67.0
Related Issues
View Source

What it does

Checks for jumps to the start of a stream that implements Seek and uses the seek method providing Start as parameter.

Why is this bad?

@@ -11691,7 +11780,7 @@

Example

t.rewind(); } -
Applicability: MachineApplicable(?)
Added in: 1.67.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.67.0
Related Issues
View Source

What it does

Checks for explicit self-assignments.

Why is this bad?

Self-assignments are redundant and unlikely to be @@ -11874,7 +11963,7 @@

Example

let x = 2;
 let y = x + 1;
-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for bindings that shadow other bindings already in scope, while just changing reference level or mutability.

Why restrict this?

@@ -11886,7 +11975,7 @@

Example

Use instead:

let y = &x; // use different variable name
-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for bindings that shadow other bindings already in scope, either without an initialization or with one that does not even use the original value.

@@ -11905,7 +11994,7 @@

Example

let x = y;
 let w = z; // use different variable name
-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for the use of short circuit boolean conditions as a statement.

@@ -11962,7 +12051,7 @@

Example

let _ = 1 / random(); } -
Applicability: HasPlaceholders(?)
Added in: 1.74.0
Related Issues
View Source

What it does

+
Applicability: HasPlaceholders(?)
Added in: 1.74.0
Related Issues
View Source

What it does

Checks for temporaries returned from function calls in a match scrutinee that have the clippy::has_significant_drop attribute.

Why is this bad?

@@ -12000,7 +12089,7 @@

Example

println!("All done!"); -
Applicability: MaybeIncorrect(?)
Added in: 1.60.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.60.0
Related Issues
View Source

What it does

Searches for elements marked with #[clippy::has_significant_drop] that could be early dropped but are in fact dropped at the end of their scopes. In other words, enforces the “tightening” of their possible lifetimes.

@@ -12190,7 +12279,7 @@

Example

bar(foo); } -
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for matches with two arms where an if let else will usually suffice.

Why is this bad?

@@ -12211,7 +12300,7 @@

Example

bar(&other_ref); } -
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for Vec or array initializations that contain only one range.

Why is this bad?

This is almost always incorrect, as it will result in a Vec that has only one element. @@ -12335,7 +12424,7 @@

Example

let mut vec = vec![2, 1, 3];
 vec.sort_unstable();
-
Applicability: MachineApplicable(?)
Added in: 1.47.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.47.0
Related Issues
View Source

What it does

Finds items imported through std when available through alloc.

Why restrict this?

Crates which have no_std compatibility and require alloc may wish to ensure types are imported from @@ -12373,19 +12462,17 @@

Known Problems

This lint cannot detect if the split is intentionally restricted to a single type of newline ("\n" or "\r\n"), for example during the parsing of a specific file format in which precisely one newline type is valid.

-
Applicability: MaybeIncorrect(?)
Added in: 1.77.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.77.0
Related Issues
View Source

What it does

This lint checks for .to_string() method calls on values of type &str.

Why restrict this?

The to_string method is also used on other types to convert them to a string. When called on a &str it turns the &str into the owned variant String, which can be more specifically expressed with .to_owned().

Example

-
// example code where clippy issues a warning
-let _ = "str".to_string();
+
let _ = "str".to_string();
 

 
Use instead:

-
// example code which does not raise clippy warning
-let _ = "str".to_owned();
+
let _ = "str".to_owned();
Applicability: MachineApplicable(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for all instances of x + _ where x is of type @@ -12495,7 +12582,7 @@

Example

Use instead:

matches!(c, '\\' | '.' | '+' | '*' | '(' | ')' | '|' | '[' | ']' | '{' | '}' | '^' | '$' | '#' | '&' | '-' | '~');
-
Applicability: MachineApplicable(?)
Added in: 1.73.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.73.0
Related Issues
View Source

What it does

Checks for slice operations on strings

Why restrict this?

UTF-8 characters span multiple bytes, and it is easy to inadvertently confuse character @@ -12515,16 +12602,14 @@

Why restrict this?

When called on a String it only clones the String, which can be more specifically expressed with .clone().

Example

-
// example code where clippy issues a warning
-let msg = String::from("Hello World");
+
let msg = String::from("Hello World");
 let _ = msg.to_string();
 

 
Use instead:

-
// example code which does not raise clippy warning
-let msg = String::from("Hello World");
+
let msg = String::from("Hello World");
 let _ = msg.clone();
 

-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for usage of libc::strlen on a CString or CStr value, and suggest calling as_bytes().len() or to_bytes().len() respectively instead.

Why is this bad?

@@ -12682,7 +12767,7 @@

Example

Use instead:

std::process::Command::new("echo").args(["-n", "hello"]).spawn().unwrap();
-
Applicability: MaybeIncorrect(?)
Added in: 1.69.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.69.0
Related Issues
View Source

What it does

Detects the use of outer doc comments (///, /**) followed by a bang (!): ///!

Why is this bad?

Triple-slash comments (known as “outer doc comments”) apply to items that follow it. @@ -12714,7 +12799,7 @@

Example

pub fn dummy() {} } -
Applicability: MaybeIncorrect(?)
Added in: 1.70.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.70.0
Related Issues
View Source

What it does

Checks for formatting of else. It lints if the else is followed immediately by a newline or the else seems to be missing.

Why is this bad?

@@ -12790,7 +12875,7 @@

Example

OpenOptions::new().create(true).truncate(true); -
Applicability: MaybeIncorrect(?)
Added in: 1.77.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.77.0
Related Issues
View Source

What it does

Checks for unlikely usages of binary operators that are almost certainly typos and/or copy/paste errors, given the other usages of binary operators nearby.

@@ -12843,7 +12928,7 @@

Example

// .. } -
Applicability: Unspecified(?)
Added in: 1.54.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.54.0
Related Issues
View Source

What it does

Checks for the usage of _.to_owned(), on a Cow<'_, _>.

Why is this bad?

Calling to_owned() on a Cow creates a clone of the Cow @@ -12875,7 +12960,7 @@

Example

let _data: String = cow.into_owned(); -
Applicability: MaybeIncorrect(?)
Added in: 1.65.0
Related Issues
View Source

What it does

+
Applicability: MaybeIncorrect(?)
Added in: 1.65.0
Related Issues
View Source

What it does

Checks the formatting of a unary operator on the right hand side of a binary operator. It lints if there is no space between the binary and unary operators, but there is a space between the unary and its operand.

@@ -12988,7 +13073,7 @@

Examples

unimplemented!(); } -
Applicability: Unspecified(?)
Added in: 1.76.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.76.0
Related Issues
View Source

What it does

Triggers when a testing function (marked with the #[test] attribute) isn’t inside a testing module (marked with #[cfg(test)]).

Why restrict this?

@@ -13069,7 +13154,7 @@

Example

} } -
Applicability: Unspecified(?)
Added in: 1.78.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.78.0
Related Issues
View Source

What it does

Checks for usage of todo!.

Why restrict this?

The todo! macro indicates the presence of unfinished code, @@ -13100,7 +13185,7 @@

Example

/// and probably spanning a many rows. struct Foo {} -
Applicability: MachineApplicable(?)
Added in: 1.82.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.82.0
Related Issues
View Source

What it does

Checks for functions with too many parameters.

Why is this bad?

Functions with lots of parameters are considered bad @@ -13118,7 +13203,7 @@

Configuration

(default: 7)

-
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: pre 1.29.0
Related Issues
View Source

What it does

Checks for functions with a large amount of lines.

Why is this bad?

Functions with a lot of lines are harder to understand @@ -13139,7 +13224,7 @@

Configuration

(default: 100)

-
Applicability: Unspecified(?)
Added in: 1.34.0
Related Issues
View Source

What it does

+
Applicability: Unspecified(?)
Added in: 1.34.0
Related Issues
View Source

What it does

Checks for function arguments and let bindings denoted as ref.

Why is this bad?

@@ -13419,7 +13504,7 @@

Example

Use instead:

" A B C ".split_whitespace();
-
Applicability: MachineApplicable(?)
Added in: 1.62.0
Related Issues
View Source

What it does

+
Applicability: MachineApplicable(?)
Added in: 1.62.0
Related Issues
View Source

What it does

Checks for trivial regex creation (with Regex::new, RegexBuilder::new, or RegexSet::new).

Why is this bad?

@@ -13474,7 +13559,7 @@

Configuration

  • trivial-copy-size-limit: The maximum size (in bytes) to consider a Copy type for passing by value instead of by -reference. By default there is no limit

    +reference.

    (default: target_pointer_width * 2)

    • @@ -13501,7 +13586,7 @@

    Example

    Ok(0) } -
    Applicability: MachineApplicable(?)
    Added in: 1.38.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: 1.38.0
    Related Issues
    View Source

    What it does

    Checks for tuple<=>array conversions that are not done with .into().

    Why is this bad?

    It may be unnecessary complexity. .into() works for converting tuples<=> arrays of up to @@ -13619,7 +13704,7 @@

    Example

    assert_eq!((*any_box).type_id(), TypeId::of::<i32>()); // ^ dereference first, to call `type_id` on `dyn Any` -
    Applicability: MaybeIncorrect(?)
    Added in: 1.73.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MaybeIncorrect(?)
    Added in: 1.73.0
    Related Issues
    View Source

    What it does

    This lint warns about unnecessary type repetitions in trait bounds

    Why is this bad?

    Repeating the type for every bound makes the code @@ -13913,7 +13998,7 @@

    Example

    WithValue(x) => x.hash(&mut state), } -
    Applicability: MaybeIncorrect(?)
    Added in: 1.58.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MaybeIncorrect(?)
    Added in: 1.58.0
    Related Issues
    View Source

    What it does

    Checks for functions that expect closures of type Fn(…) -> Ord where the implemented closure returns the unit type. The lint also suggests to remove the semi-colon at the end of the statement if present.

    @@ -13979,7 +14064,7 @@

    Example

    let _ = 2_i32;
 let _ = 0.5_f32;
    -
    Applicability: MachineApplicable(?)
    Added in: pre 1.29.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: pre 1.29.0
    Related Issues
    View Source

    What it does

    Checks for #[cfg_attr(clippy, allow(clippy::lint))] and suggests to replace it with #[allow(clippy::lint)].

    Why is this bad?

    @@ -13991,7 +14076,7 @@

    Example

    Use instead:

    #![allow(clippy::deprecated_cfg_attr)]
    -
    Applicability: MachineApplicable(?)
    Added in: 1.78.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: 1.78.0
    Related Issues
    View Source

    What it does

    Checks for calls to TryInto::try_into and TryFrom::try_from when their infallible counterparts could be used.

    Why is this bad?

    @@ -14007,7 +14092,7 @@

    Example

    let _: i64 = 1i32.into();
 let _: i64 = <_>::from(1i32);
    -
    Applicability: MachineApplicable(?)
    Added in: 1.75.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: 1.75.0
    Related Issues
    View Source

    What it does

    Checks for filter_map calls that could be replaced by filter or map. More specifically it checks if the closure provided is only performing one of the filter or map operations and suggests the appropriate option.

    @@ -14060,7 +14145,7 @@

    Example

    // The vector is empty... } -
    Applicability: MachineApplicable(?)
    Added in: 1.83.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: 1.83.0
    Related Issues
    View Source

    What it does

    Checks for usage of fold when a more succinct alternative exists. Specifically, this checks for folds which could be replaced by any, all, sum or product.

    @@ -14088,7 +14173,7 @@

    Example

    // code } -
    Applicability: MaybeIncorrect(?)
    Added in: 1.78.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MaybeIncorrect(?)
    Added in: 1.78.0
    Related Issues
    View Source

    What it does

    Checks for usage of .collect::<Vec<String>>().join("") on iterators.

    Why is this bad?

    .collect::<String>() is more concise and might be more performant

    @@ -14108,7 +14193,7 @@

    Known problems

    will prevent loop unrolling and will result in a negative performance impact.

    Additionally, differences have been observed between aarch64 and x86_64 assembly output, with aarch64 tending to producing faster assembly in more cases when using .collect::<String>()

    -
    Applicability: MachineApplicable(?)
    Added in: 1.61.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: 1.61.0
    Related Issues
    View Source

    What it does

    As the counterpart to or_fun_call, this lint looks for unnecessary lazily evaluated closures on Option and Result.

    This lint suggests changing the following functions, when eager evaluation results in @@ -14127,8 +14212,7 @@

    Known problems

    It is possible, but not recommended for Deref and Index to have side effects. Eagerly evaluating them can change the semantics of the program.

    Example

    -
    // example code where clippy issues a warning
-let opt: Option<u32> = None;
+
    let opt: Option<u32> = None;
 
 opt.unwrap_or_else(|| 42);
 
    
@@ -14147,7 +14231,7 @@ 
    Configuration
    Applicability: MachineApplicable(?)
    Added in: 1.48.0
    Related Issues
    View Source

    What it does

    Detects functions that are written to return &str that could return &'static str but instead return a &'a str.

    Why is this bad?

    -

    This leaves the caller unable to use the &str as &'static str, causing unneccessary allocations or confusion. +

    This leaves the caller unable to use the &str as &'static str, causing unnecessary allocations or confusion. This is also most likely what you meant to write.

    Example

    impl MyType {
@@ -14201,25 +14285,33 @@ 
    Example
    
 
    Why is this bad?
    
 
    Calls such as opt.map_or(false, |val| val == 5) are needlessly long and cumbersome,
 and can be reduced to, for example, opt == Some(5) assuming opt implements PartialEq.
+Also, calls such as opt.map_or(true, |val| val == 5) can be reduced to
+opt.is_none_or(|val| val == 5).
 This lint offers readability and conciseness improvements.
    
 
    Example
    
-
    pub fn a(x: Option<i32>) -> bool {
-    x.map_or(false, |n| n == 5)
+
    pub fn a(x: Option<i32>) -> (bool, bool) {
+    (
+        x.map_or(false, |n| n == 5),
+        x.map_or(true, |n| n > 5),
+    )
 }
 
    
 
    Use instead:
    
-
    pub fn a(x: Option<i32>) -> bool {
-    x == Some(5)
+
    pub fn a(x: Option<i32>) -> (bool, bool) {
+    (
+        x == Some(5),
+        x.is_none_or(|n| n > 5),
+    )
 }
 
    
-
    Applicability: MaybeIncorrect(?)
    Added in: 1.75.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: 1.84.0
    Related Issues
    View Source

    What it does

    Checks for unnecessary calls to min() or max() in the following cases

    • Either both side is constant
    • One side is clearly larger than the other, like i32::MIN and an i32 variable

    Why is this bad?

    -

    In the aformentioned cases it is not necessary to call min() or max() +

    In the aforementioned cases it is not necessary to call min() or max() to compare values, it may even cause confusion.

    Example

    let _ = 0.min(7_u32);
@@ -14227,7 +14319,7 @@ 
    Example
    
 
    Use instead:
    
 
    let _ = 0;
 
    
-
    Applicability: MachineApplicable(?)
    Added in: 1.81.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: 1.81.0
    Related Issues
    View Source

    What it does

    Detects passing a mutable reference to a function that only requires an immutable reference.

    Why is this bad?

    @@ -14270,7 +14362,7 @@

    Example

    let x: Result<u32, ()> = Ok(0);
 let y = x.unwrap_or_else(|err| handle_error(err));
    -
    Applicability: MachineApplicable(?)
    Added in: 1.78.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: 1.78.0
    Related Issues
    View Source

    What it does

    Checks for // SAFETY: comments on safe code.

    Why restrict this?

    Safe code has no safety requirements, so there is no need to @@ -14316,7 +14408,7 @@

    Configuration

    (default: false)

    -
    Applicability: Unspecified(?)
    Added in: 1.67.0
    Related Issues
    View Source

    What it does

    +
    Applicability: Unspecified(?)
    Added in: 1.67.0
    Related Issues
    View Source

    What it does

    Checks for imports ending in ::{self}.

    Why restrict this?

    In most cases, this can be written much more cleanly by omitting ::{self}.

    @@ -14346,7 +14438,7 @@

    Example

    Use instead:

    vec.sort_by_key(|a| a.foo());
    -
    Applicability: MachineApplicable(?)
    Added in: 1.46.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: 1.46.0
    Related Issues
    View Source

    What it does

    Checks for initialization of an identical struct from another instance of the type, either by copying a base without setting any field or by moving all fields individually.

    @@ -14389,7 +14481,7 @@

    Example

    foo(&path.to_string_lossy()); fn foo(s: &str) {}     -
    Applicability: MachineApplicable(?)
    Added in: 1.59.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: 1.59.0
    Related Issues
    View Source

    What it does

    Checks for calls of unwrap[_err]() that cannot fail.

    Why is this bad?

    Using if let or match is more idiomatic.

    @@ -14557,7 +14649,7 @@

    Example

    } }     -
    Applicability: Unspecified(?)
    Added in: 1.45.0
    Related Issues
    View Source

    What it does

    +
    Applicability: Unspecified(?)
    Added in: 1.45.0
    Related Issues
    View Source

    What it does

    Checks for imports that remove “unsafe” from an item’s name.

    Why is this bad?

    @@ -15038,7 +15130,7 @@

    Example

    let _ = FooStruct{}; } -
    Applicability: Unspecified(?)
    Added in: pre 1.29.0
    Related Issues
    View Source

    What it does

    +
    Applicability: Unspecified(?)
    Added in: 1.83.0
    Related Issues
    View Source

    What it does

    Checks for usage of .as_ref() or .as_mut() where the types before and after the call are the same.

    Why is this bad?

    @@ -15094,7 +15186,7 @@

    Example

    #[macro_use] extern crate baz; -
    Applicability: MaybeIncorrect(?)
    Added in: pre 1.29.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MaybeIncorrect(?)
    Added in: pre 1.29.0
    Related Issues
    View Source

    What it does

    Checks for Into, TryInto, From, TryFrom, or IntoIter calls which uselessly convert to the same type.

    Why is this bad?

    @@ -15110,7 +15202,7 @@

    Past names

    • identity_conversion
    -
    Applicability: MachineApplicable(?)
    Added in: 1.45.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: 1.45.0
    Related Issues
    View Source

    What it does

    Checks for the use of format!("string literal with no argument") and format!("{}", foo) where foo is a string.

    Why is this bad?

    There is no point of doing that. format!("foo") can @@ -15250,7 +15342,7 @@

    Example

    Use instead:

    vec![1, 2, 3, 4, 5].clear()
    -
    Applicability: MaybeIncorrect(?)
    Added in: 1.46.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MaybeIncorrect(?)
    Added in: 1.46.0
    Related Issues
    View Source

    What it does

    Checks for bit masks that can be replaced by a call to trailing_zeros

    Why is this bad?

    @@ -15283,7 +15375,7 @@

    Example

    Can be written more concisely as

    let mut bytes = fs::read("foo.txt").unwrap();
    -
    Applicability: Unspecified(?)
    Added in: 1.44.0
    Related Issues
    View Source

    What it does

    +
    Applicability: Unspecified(?)
    Added in: 1.44.0
    Related Issues
    View Source

    What it does

    Checks for usage of waker.clone().wake()

    Why is this bad?

    Cloning the waker is not necessary, wake_by_ref() enables the same operation @@ -15294,7 +15386,7 @@

    Example

    Should be written

    waker.wake_by_ref();
    -
    Applicability: MachineApplicable(?)
    Added in: 1.75.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: 1.75.0
    Related Issues
    View Source

    What it does

    Checks for while loops comparing floating point values.

    Why is this bad?

    If you increment floating point values, errors can compound, @@ -15396,7 +15488,7 @@

    Example

    Foo::B(_) => {}, } -
    Applicability: MaybeIncorrect(?)
    Added in: 1.34.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MaybeIncorrect(?)
    Added in: 1.34.0
    Related Issues
    View Source

    What it does

    Checks for wildcard imports use _::*.

    Why is this bad?

    wildcard imports can pollute the namespace. This is especially bad if @@ -15466,7 +15558,7 @@

    Example

    _ => {}, } -
    Applicability: Unspecified(?)
    Added in: 1.42.0
    Related Issues
    View Source

    What it does

    +
    Applicability: Unspecified(?)
    Added in: 1.42.0
    Related Issues
    View Source

    What it does

    This lint warns about the use of literals as write!/writeln! args.

    Why is this bad?

    Using literals as writeln! args is inefficient @@ -15611,7 +15703,7 @@

    Example

    Use instead:

    let a = std::ptr::null::<u32>();
    -
    Applicability: MachineApplicable(?)
    Added in: pre 1.29.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MachineApplicable(?)
    Added in: pre 1.29.0
    Related Issues
    View Source

    What it does

    Checks for array or vec initializations which call a function or method, but which have a repeat count of zero.

    Why is this bad?

    @@ -15661,6 +15753,15 @@

    Why is this bad?

    Not doing so will effectively leak process IDs and/or other limited global resources, which can eventually lead to resource exhaustion, so it’s recommended to call wait() in long-running applications. Such processes are called “zombie processes”.

    +

    To reduce the rate of false positives, if the spawned process is assigned to a binding, the lint actually works the other way around; it +conservatively checks that all uses of a variable definitely don’t call wait() and only then emits a warning. +For that reason, a seemingly unrelated use can get called out as calling wait() in help messages.

    +

    Control flow

    +

    If a wait() call exists in an if/then block but not in the else block (or there is no else block), +then this still gets linted as not calling wait() in all code paths. +Likewise, when early-returning from the function, wait() calls that appear after the return expression +are also not accepted. +In other words, the wait() call must be unconditionally reachable after the spawn expression.

    Example

    use std::process::Command;
 
@@ -15672,7 +15773,7 @@ 
    Example
    
 let mut child = Command::new("ls").spawn().expect("failed to execute child");
 child.wait().expect("failed to wait on child");
    -
    Applicability: MaybeIncorrect(?)
    Added in: 1.74.0
    Related Issues
    View Source

    What it does

    +
    Applicability: MaybeIncorrect(?)
    Added in: 1.83.0
    Related Issues
    View Source

    What it does

    Checks for offset(_), wrapping_{add, sub}, etc. on raw pointers to zero-sized types

    Why is this bad?

    diff --git a/beta/script.js b/beta/script.js index 9a5365b2158b..c2197b89c566 100644 --- a/beta/script.js +++ b/beta/script.js @@ -232,13 +232,13 @@ const APPLICABILITIES_FILTER_DEFAULT = { MaybeIncorrect: true, HasPlaceholders: true, }; -const URL_PARAMS_CORRESPONDANCE = { +const URL_PARAMS_CORRESPONDENCE = { "groups_filter": "groups", "levels_filter": "levels", "applicabilities_filter": "applicabilities", "version_filter": "versions", }; -const VERSIONS_CORRESPONDANCE = { +const VERSIONS_CORRESPONDENCE = { "lte": "≤", "gte": "≥", "eq": "=", @@ -285,7 +285,7 @@ window.filters = { } function updateIfNeeded(filterName, obj2) { const obj1 = filters[filterName]; - const name = URL_PARAMS_CORRESPONDANCE[filterName]; + const name = URL_PARAMS_CORRESPONDENCE[filterName]; if (!compareObjects(obj1, obj2)) { urlParams.set( name, @@ -316,9 +316,9 @@ window.filters = { versions.push(`lte:${filters.version_filter["≤"]}`); } if (versions.length !== 0) { - urlParams.set(URL_PARAMS_CORRESPONDANCE["version_filter"], versions.join(",")); + urlParams.set(URL_PARAMS_CORRESPONDENCE["version_filter"], versions.join(",")); } else { - urlParams.delete(URL_PARAMS_CORRESPONDANCE["version_filter"]); + urlParams.delete(URL_PARAMS_CORRESPONDENCE["version_filter"]); } let params = urlParams.toString(); @@ -532,7 +532,7 @@ function parseURLFilters() { const urlParams = new URLSearchParams(window.location.search); for (const [key, value] of urlParams.entries()) { - for (const [corres_key, corres_value] of Object.entries(URL_PARAMS_CORRESPONDANCE)) { + for (const [corres_key, corres_value] of Object.entries(URL_PARAMS_CORRESPONDENCE)) { if (corres_value === key) { if (key !== "versions") { const settings = new Set(value.split(",")); @@ -545,7 +545,7 @@ function parseURLFilters() { for (const [kind, value] of settings) { const elem = document.querySelector( - `#version-filter input[data-value="${VERSIONS_CORRESPONDANCE[kind]}"]`); + `#version-filter input[data-value="${VERSIONS_CORRESPONDENCE[kind]}"]`); elem.value = value; updateVersionFilters(elem, true); }