diff --git a/master/lints.json b/master/lints.json index c852a3924188..596f0655b710 100644 --- a/master/lints.json +++ b/master/lints.json @@ -7,7 +7,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for usage of items through absolute paths, like `std::env::current_dir`.\n\n### Why is this bad?\nMany codebases have their own style when it comes to importing, but one that is seldom used\nis using absolute paths *everywhere*. This is generally considered unidiomatic, and you\nshould add a `use` statement.\n\nThe default maximum segments (2) is pretty strict, you may want to increase this in\n`clippy.toml`.\n\nNote: One exception to this is code from macro expansion - this does not lint such cases, as\nusing absolute paths is the proper way of referencing items in one.\n\n### Example\n```rust\nlet x = std::f64::consts::PI;\n```\nUse any of the below instead, or anything else:\n```rust\nuse std::f64;\nuse std::f64::consts;\nuse std::f64::consts::PI;\nlet x = f64::consts::PI;\nlet x = consts::PI;\nlet x = PI;\nuse std::f64::consts as f64_consts;\nlet x = f64_consts::PI;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `absolute-paths-max-segments`: `u64`(defaults to `2`): The maximum number of segments a path can have before being linted, anything above this will\n be linted.\n* `absolute-paths-allowed-crates`: `rustc_data_structures::fx::FxHashSet`(defaults to `{}`): Which crates to allow absolute paths from\n", + "docs": "\n### What it does\nChecks for usage of items through absolute paths, like `std::env::current_dir`.\n\n### Why is this bad?\nMany codebases have their own style when it comes to importing, but one that is seldom used\nis using absolute paths *everywhere*. This is generally considered unidiomatic, and you\nshould add a `use` statement.\n\nThe default maximum segments (2) is pretty strict, you may want to increase this in\n`clippy.toml`.\n\nNote: One exception to this is code from macro expansion - this does not lint such cases, as\nusing absolute paths is the proper way of referencing items in one.\n\n### Example\n```rust\nlet x = std::f64::consts::PI;\n```\nUse any of the below instead, or anything else:\n```rust\nuse std::f64;\nuse std::f64::consts;\nuse std::f64::consts::PI;\nlet x = f64::consts::PI;\nlet x = consts::PI;\nlet x = PI;\nuse std::f64::consts as f64_consts;\nlet x = f64_consts::PI;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `absolute-paths-max-segments`: The maximum number of segments a path can have before being linted, anything above this will\n be linted. (default: `2`)- `absolute-paths-allowed-crates`: Which crates to allow absolute paths from (default: `[]`)", "version": "1.73.0", "applicability": { "is_multi_part_suggestion": false, @@ -82,7 +82,7 @@ }, "group": "suspicious", "level": "warn", - "docs": "\n### What it does\nChecks for ranges which almost include the entire range of letters from 'a' to 'z'\nor digits from '0' to '9', but don't because they're a half open range.\n\n### Why is this bad?\nThis (`'a'..'z'`) is almost certainly a typo meant to include all letters.\n\n### Example\n```rust\nlet _ = 'a'..'z';\n```\nUse instead:\n```rust\nlet _ = 'a'..='z';\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n\n### Past names\n\n* `almost_complete_letter_range`\n\n", + "docs": "\n### What it does\nChecks for ranges which almost include the entire range of letters from 'a' to 'z'\nor digits from '0' to '9', but don't because they're a half open range.\n\n### Why is this bad?\nThis (`'a'..'z'`) is almost certainly a typo meant to include all letters.\n\n### Example\n```rust\nlet _ = 'a'..'z';\n```\nUse instead:\n```rust\nlet _ = 'a'..='z';\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`\n### Past names\n\n* `almost_complete_letter_range`\n\n", "version": "1.68.0", "applicability": { "is_multi_part_suggestion": false, @@ -115,7 +115,7 @@ }, "group": "correctness", "level": "deny", - "docs": "\n### What it does\nChecks for floating point literals that approximate\nconstants which are defined in\n[`std::f32::consts`](https://doc.rust-lang.org/stable/std/f32/consts/#constants)\nor\n[`std::f64::consts`](https://doc.rust-lang.org/stable/std/f64/consts/#constants),\nrespectively, suggesting to use the predefined constant.\n\n### Why is this bad?\nUsually, the definition in the standard library is more\nprecise than what people come up with. If you find that your definition is\nactually more precise, please [file a Rust\nissue](https://github.com/rust-lang/rust/issues).\n\n### Example\n```rust\nlet x = 3.14;\nlet y = 1_f64 / x;\n```\nUse instead:\n```rust\nlet x = std::f32::consts::PI;\nlet y = std::f64::consts::FRAC_1_PI;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for floating point literals that approximate\nconstants which are defined in\n[`std::f32::consts`](https://doc.rust-lang.org/stable/std/f32/consts/#constants)\nor\n[`std::f64::consts`](https://doc.rust-lang.org/stable/std/f64/consts/#constants),\nrespectively, suggesting to use the predefined constant.\n\n### Why is this bad?\nUsually, the definition in the standard library is more\nprecise than what people come up with. If you find that your definition is\nactually more precise, please [file a Rust\nissue](https://github.com/rust-lang/rust/issues).\n\n### Example\n```rust\nlet x = 3.14;\nlet y = 1_f64 / x;\n```\nUse instead:\n```rust\nlet x = std::f32::consts::PI;\nlet y = std::f64::consts::FRAC_1_PI;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -145,7 +145,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks any kind of arithmetic operation of any type.\n\nOperators like `+`, `-`, `*` or `<<` are usually capable of overflowing according to the [Rust\nReference](https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow),\nor can panic (`/`, `%`).\n\nKnown safe built-in types like `Wrapping` or `Saturating`, floats, operations in constant\nenvironments, allowed types and non-constant operations that won't overflow are ignored.\n\n### Why is this bad?\nFor integers, overflow will trigger a panic in debug builds or wrap the result in\nrelease mode; division by zero will cause a panic in either mode. As a result, it is\ndesirable to explicitly call checked, wrapping or saturating arithmetic methods.\n\n#### Example\n```rust\n// `n` can be any number, including `i32::MAX`.\nfn foo(n: i32) -> i32 {\n n + 1\n}\n```\n\nThird-party types can also overflow or present unwanted side-effects.\n\n#### Example\n```rust\nuse rust_decimal::Decimal;\nlet _n = Decimal::MAX + Decimal::MAX;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `arithmetic-side-effects-allowed`: `rustc_data_structures::fx::FxHashSet`(defaults to `{}`): Suppress checking of the passed type names in all types of operations.\n\n If a specific operation is desired, consider using `arithmetic_side_effects_allowed_binary` or `arithmetic_side_effects_allowed_unary` instead.\n\n #### Example\n\n```toml\n arithmetic-side-effects-allowed = [\"SomeType\", \"AnotherType\"]\n ```\n\n #### Noteworthy\n\n A type, say `SomeType`, listed in this configuration has the same behavior of\n `[\"SomeType\" , \"*\"], [\"*\", \"SomeType\"]` in `arithmetic_side_effects_allowed_binary`.\n* `arithmetic-side-effects-allowed-binary`: `Vec<[String; 2]>`(defaults to `[]`): Suppress checking of the passed type pair names in binary operations like addition or\n multiplication.\n\n Supports the \"*\" wildcard to indicate that a certain type won't trigger the lint regardless\n of the involved counterpart. For example, `[\"SomeType\", \"*\"]` or `[\"*\", \"AnotherType\"]`.\n\n Pairs are asymmetric, which means that `[\"SomeType\", \"AnotherType\"]` is not the same as\n `[\"AnotherType\", \"SomeType\"]`.\n\n #### Example\n\n```toml\n arithmetic-side-effects-allowed-binary = [[\"SomeType\" , \"f32\"], [\"AnotherType\", \"*\"]]\n ```\n* `arithmetic-side-effects-allowed-unary`: `rustc_data_structures::fx::FxHashSet`(defaults to `{}`): Suppress checking of the passed type names in unary operations like \"negation\" (`-`).\n\n #### Example\n\n```toml\n arithmetic-side-effects-allowed-unary = [\"SomeType\", \"AnotherType\"]\n ```\n\n### Past names\n\n* `integer_arithmetic`\n\n", + "docs": "\n### What it does\nChecks any kind of arithmetic operation of any type.\n\nOperators like `+`, `-`, `*` or `<<` are usually capable of overflowing according to the [Rust\nReference](https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow),\nor can panic (`/`, `%`).\n\nKnown safe built-in types like `Wrapping` or `Saturating`, floats, operations in constant\nenvironments, allowed types and non-constant operations that won't overflow are ignored.\n\n### Why is this bad?\nFor integers, overflow will trigger a panic in debug builds or wrap the result in\nrelease mode; division by zero will cause a panic in either mode. As a result, it is\ndesirable to explicitly call checked, wrapping or saturating arithmetic methods.\n\n#### Example\n```rust\n// `n` can be any number, including `i32::MAX`.\nfn foo(n: i32) -> i32 {\n n + 1\n}\n```\n\nThird-party types can also overflow or present unwanted side-effects.\n\n#### Example\n```rust\nuse rust_decimal::Decimal;\nlet _n = Decimal::MAX + Decimal::MAX;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `arithmetic-side-effects-allowed`: Suppress checking of the passed type names in all types of operations.\n\n If a specific operation is desired, consider using `arithmetic_side_effects_allowed_binary` or `arithmetic_side_effects_allowed_unary` instead.\n\n #### Example\n\n```toml\n arithmetic-side-effects-allowed = [\"SomeType\", \"AnotherType\"]\n ```\n\n #### Noteworthy\n\n A type, say `SomeType`, listed in this configuration has the same behavior of\n `[\"SomeType\" , \"*\"], [\"*\", \"SomeType\"]` in `arithmetic_side_effects_allowed_binary`. (default: `[]`)- `arithmetic-side-effects-allowed-binary`: Suppress checking of the passed type pair names in binary operations like addition or\n multiplication.\n\n Supports the \"*\" wildcard to indicate that a certain type won't trigger the lint regardless\n of the involved counterpart. For example, `[\"SomeType\", \"*\"]` or `[\"*\", \"AnotherType\"]`.\n\n Pairs are asymmetric, which means that `[\"SomeType\", \"AnotherType\"]` is not the same as\n `[\"AnotherType\", \"SomeType\"]`.\n\n #### Example\n\n```toml\n arithmetic-side-effects-allowed-binary = [[\"SomeType\" , \"f32\"], [\"AnotherType\", \"*\"]]\n ``` (default: `[]`)- `arithmetic-side-effects-allowed-unary`: Suppress checking of the passed type names in unary operations like \"negation\" (`-`).\n\n #### Example\n\n```toml\n arithmetic-side-effects-allowed-unary = [\"SomeType\", \"AnotherType\"]\n ``` (default: `[]`)\n### Past names\n\n* `integer_arithmetic`\n\n", "version": "1.64.0", "applicability": { "is_multi_part_suggestion": false, @@ -279,11 +279,11 @@ "id": "await_holding_invalid_type", "id_span": { "path": "src/await_holding_invalid.rs", - "line": 165 + "line": 164 }, "group": "suspicious", "level": "warn", - "docs": "\n### What it does\nAllows users to configure types which should not be held across `await`\nsuspension points.\n\n### Why is this bad?\nThere are some types which are perfectly \"safe\" to be used concurrently\nfrom a memory access perspective but will cause bugs at runtime if they\nare held in such a way.\n\n### Example\n\n```toml\nawait-holding-invalid-types = [\n # You can specify a type name\n \"CustomLockType\",\n # You can (optionally) specify a reason\n { path = \"OtherCustomLockType\", reason = \"Relies on a thread local\" }\n]\n```\n\n```rust\nstruct CustomLockType;\nstruct OtherCustomLockType;\nasync fn foo() {\n let _x = CustomLockType;\n let _y = OtherCustomLockType;\n baz().await; // Lint violation\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `await-holding-invalid-types`: `Vec`(defaults to `[]`): \n", + "docs": "\n### What it does\nAllows users to configure types which should not be held across `await`\nsuspension points.\n\n### Why is this bad?\nThere are some types which are perfectly \"safe\" to be used concurrently\nfrom a memory access perspective but will cause bugs at runtime if they\nare held in such a way.\n\n### Example\n\n```toml\nawait-holding-invalid-types = [\n # You can specify a type name\n \"CustomLockType\",\n # You can (optionally) specify a reason\n { path = \"OtherCustomLockType\", reason = \"Relies on a thread local\" }\n]\n```\n\n```rust\nstruct CustomLockType;\nstruct OtherCustomLockType;\nasync fn foo() {\n let _x = CustomLockType;\n let _y = OtherCustomLockType;\n baz().await; // Lint violation\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `await-holding-invalid-types`: (default: `[]`)", "version": "1.62.0", "applicability": { "is_multi_part_suggestion": false, @@ -294,7 +294,7 @@ "id": "await_holding_lock", "id_span": { "path": "src/await_holding_invalid.rs", - "line": 70 + "line": 69 }, "group": "suspicious", "level": "warn", @@ -309,7 +309,7 @@ "id": "await_holding_refcell_ref", "id_span": { "path": "src/await_holding_invalid.rs", - "line": 128 + "line": 127 }, "group": "suspicious", "level": "warn", @@ -455,7 +455,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for the usage of `&expr as *const T` or\n`&mut expr as *mut T`, and suggest using `ptr::addr_of` or\n`ptr::addr_of_mut` instead.\n\n### Why is this bad?\nThis would improve readability and avoid creating a reference\nthat points to an uninitialized value or unaligned place.\nRead the `ptr::addr_of` docs for more information.\n\n### Example\n```rust\nlet val = 1;\nlet p = &val as *const i32;\n\nlet mut val_mut = 1;\nlet p_mut = &mut val_mut as *mut i32;\n```\nUse instead:\n```rust\nlet val = 1;\nlet p = std::ptr::addr_of!(val);\n\nlet mut val_mut = 1;\nlet p_mut = std::ptr::addr_of_mut!(val_mut);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for the usage of `&expr as *const T` or\n`&mut expr as *mut T`, and suggest using `ptr::addr_of` or\n`ptr::addr_of_mut` instead.\n\n### Why is this bad?\nThis would improve readability and avoid creating a reference\nthat points to an uninitialized value or unaligned place.\nRead the `ptr::addr_of` docs for more information.\n\n### Example\n```rust\nlet val = 1;\nlet p = &val as *const i32;\n\nlet mut val_mut = 1;\nlet p_mut = &mut val_mut as *mut i32;\n```\nUse instead:\n```rust\nlet val = 1;\nlet p = std::ptr::addr_of!(val);\n\nlet mut val_mut = 1;\nlet p_mut = std::ptr::addr_of_mut!(val_mut);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.60.0", "applicability": { "is_multi_part_suggestion": false, @@ -515,7 +515,7 @@ }, "group": "perf", "level": "warn", - "docs": "\n### What it does\nChecks for usage of `Box` where T is a collection such as Vec anywhere in the code.\nCheck the [Box documentation](https://doc.rust-lang.org/std/boxed/index.html) for more information.\n\n### Why is this bad?\nCollections already keeps their contents in a separate area on\nthe heap. So if you `Box` them, you just add another level of indirection\nwithout any benefit whatsoever.\n\n### Example\n```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n\n### Past names\n\n* `box_vec`\n\n", + "docs": "\n### What it does\nChecks for usage of `Box` where T is a collection such as Vec anywhere in the code.\nCheck the [Box documentation](https://doc.rust-lang.org/std/boxed/index.html) for more information.\n\n### Why is this bad?\nCollections already keeps their contents in a separate area on\nthe heap. So if you `Box` them, you just add another level of indirection\nwithout any benefit whatsoever.\n\n### Example\n```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)\n### Past names\n\n* `box_vec`\n\n", "version": "1.57.0", "applicability": { "is_multi_part_suggestion": false, @@ -548,7 +548,7 @@ }, "group": "perf", "level": "warn", - "docs": "\n### What it does\nChecks for usage of `Box` where an unboxed `T` would\nwork fine.\n\n### Why is this bad?\nThis is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.\n\n### Example\n```rust\nfn foo(x: Box) {}\n```\n\nUse instead:\n```rust\nfn foo(x: u32) {}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `too-large-for-stack`: `u64`(defaults to `200`): The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap\n", + "docs": "\n### What it does\nChecks for usage of `Box` where an unboxed `T` would\nwork fine.\n\n### Why is this bad?\nThis is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.\n\n### Example\n```rust\nfn foo(x: Box) {}\n```\n\nUse instead:\n```rust\nfn foo(x: u32) {}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `too-large-for-stack`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (default: `200`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -623,7 +623,7 @@ }, "group": "cargo", "level": "allow", - "docs": "\n### What it does\nChecks to see if all common metadata is defined in\n`Cargo.toml`. See: https://rust-lang-nursery.github.io/api-guidelines/documentation.html#cargotoml-includes-all-common-metadata-c-metadata\n\n### Why is this bad?\nIt will be more difficult for users to discover the\npurpose of the crate, and key information related to it.\n\n### Example\n```toml\n# This `Cargo.toml` is missing a description field:\n[package]\nname = \"clippy\"\nversion = \"0.0.212\"\nrepository = \"https://github.com/rust-lang/rust-clippy\"\nreadme = \"README.md\"\nlicense = \"MIT OR Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```\n\nShould include a description field like:\n\n```toml\n# This `Cargo.toml` includes all common metadata\n[package]\nname = \"clippy\"\nversion = \"0.0.212\"\ndescription = \"A bunch of helpful lints to avoid common pitfalls in Rust\"\nrepository = \"https://github.com/rust-lang/rust-clippy\"\nreadme = \"README.md\"\nlicense = \"MIT OR Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```", + "docs": "\n### What it does\nChecks to see if all common metadata is defined in\n`Cargo.toml`. See: https://rust-lang-nursery.github.io/api-guidelines/documentation.html#cargotoml-includes-all-common-metadata-c-metadata\n\n### Why is this bad?\nIt will be more difficult for users to discover the\npurpose of the crate, and key information related to it.\n\n### Example\n```toml\n# This `Cargo.toml` is missing a description field:\n[package]\nname = \"clippy\"\nversion = \"0.0.212\"\nrepository = \"https://github.com/rust-lang/rust-clippy\"\nreadme = \"README.md\"\nlicense = \"MIT OR Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```\n\nShould include a description field like:\n\n```toml\n# This `Cargo.toml` includes all common metadata\n[package]\nname = \"clippy\"\nversion = \"0.0.212\"\ndescription = \"A bunch of helpful lints to avoid common pitfalls in Rust\"\nrepository = \"https://github.com/rust-lang/rust-clippy\"\nreadme = \"README.md\"\nlicense = \"MIT OR Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `cargo-ignore-publish`: For internal testing only, ignores the current `publish` settings in the Cargo manifest. (default: `false`)", "version": "1.32.0", "applicability": { "is_multi_part_suggestion": false, @@ -653,7 +653,7 @@ }, "group": "suspicious", "level": "warn", - "docs": "\n### What it does\nChecks for usage of the `abs()` method that cast the result to unsigned.\n\n### Why is this bad?\nThe `unsigned_abs()` method avoids panic when called on the MIN value.\n\n### Example\n```rust\nlet x: i32 = -42;\nlet y: u32 = x.abs() as u32;\n```\nUse instead:\n```rust\nlet x: i32 = -42;\nlet y: u32 = x.unsigned_abs();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for usage of the `abs()` method that cast the result to unsigned.\n\n### Why is this bad?\nThe `unsigned_abs()` method avoids panic when called on the MIN value.\n\n### Example\n```rust\nlet x: i32 = -42;\nlet y: u32 = x.abs() as u32;\n```\nUse instead:\n```rust\nlet x: i32 = -42;\nlet y: u32 = x.unsigned_abs();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.62.0", "applicability": { "is_multi_part_suggestion": false, @@ -878,7 +878,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for explicit bounds checking when casting.\n\n### Why is this bad?\nReduces the readability of statements & is error prone.\n\n### Example\n```rust\nfoo <= i32::MAX as u32;\n```\n\nUse instead:\n```rust\ni32::try_from(foo).is_ok();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for explicit bounds checking when casting.\n\n### Why is this bad?\nReduces the readability of statements & is error prone.\n\n### Example\n```rust\nfoo <= i32::MAX as u32;\n```\n\nUse instead:\n```rust\ni32::try_from(foo).is_ok();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.37.0", "applicability": { "is_multi_part_suggestion": false, @@ -938,7 +938,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for usage of `cloned()` on an `Iterator` or `Option` where\n`copied()` could be used instead.\n\n### Why is this bad?\n`copied()` is better because it guarantees that the type being cloned\nimplements `Copy`.\n\n### Example\n```rust\n[1, 2, 3].iter().cloned();\n```\nUse instead:\n```rust\n[1, 2, 3].iter().copied();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for usage of `cloned()` on an `Iterator` or `Option` where\n`copied()` could be used instead.\n\n### Why is this bad?\n`copied()` is better because it guarantees that the type being cloned\nimplements `Copy`.\n\n### Example\n```rust\n[1, 2, 3].iter().cloned();\n```\nUse instead:\n```rust\n[1, 2, 3].iter().copied();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.53.0", "applicability": { "is_multi_part_suggestion": false, @@ -983,7 +983,7 @@ }, "group": "nursery", "level": "allow", - "docs": "\n### What it does\nChecks for methods with high cognitive complexity.\n\n### Why is this bad?\nMethods of high cognitive complexity tend to be hard to\nboth read and maintain. Also LLVM will tend to optimize small methods better.\n\n### Known problems\nSometimes it's hard to find a way to reduce the\ncomplexity.\n\n### Example\nYou'll see it when you get the warning.\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `cognitive-complexity-threshold`: `u64`(defaults to `25`): The maximum cognitive complexity a function can have\n\n### Past names\n\n* `cyclomatic_complexity`\n\n", + "docs": "\n### What it does\nChecks for methods with high cognitive complexity.\n\n### Why is this bad?\nMethods of high cognitive complexity tend to be hard to\nboth read and maintain. Also LLVM will tend to optimize small methods better.\n\n### Known problems\nSometimes it's hard to find a way to reduce the\ncomplexity.\n\n### Example\nYou'll see it when you get the warning.\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `cognitive-complexity-threshold`: The maximum cognitive complexity a function can have (default: `25`)\n### Past names\n\n* `cyclomatic_complexity`\n\n", "version": "1.35.0", "applicability": { "is_multi_part_suggestion": false, @@ -1046,7 +1046,7 @@ }, "group": "perf", "level": "warn", - "docs": "\n### What it does\nChecks for consecutive calls to `str::replace` (2 or more)\nthat can be collapsed into a single call.\n\n### Why is this bad?\nConsecutive `str::replace` calls scan the string multiple times\nwith repetitive code.\n\n### Example\n```rust\nlet hello = \"hesuo worpd\"\n .replace('s', \"l\")\n .replace(\"u\", \"l\")\n .replace('p', \"l\");\n```\nUse instead:\n```rust\nlet hello = \"hesuo worpd\".replace(['s', 'u', 'p'], \"l\");\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for consecutive calls to `str::replace` (2 or more)\nthat can be collapsed into a single call.\n\n### Why is this bad?\nConsecutive `str::replace` calls scan the string multiple times\nwith repetitive code.\n\n### Example\n```rust\nlet hello = \"hesuo worpd\"\n .replace('s', \"l\")\n .replace(\"u\", \"l\")\n .replace('p', \"l\");\n```\nUse instead:\n```rust\nlet hello = \"hesuo worpd\".replace(['s', 'u', 'p'], \"l\");\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.65.0", "applicability": { "is_multi_part_suggestion": false, @@ -1166,7 +1166,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for usage of the [`dbg!`](https://doc.rust-lang.org/std/macro.dbg.html) macro.\n\n### Why is this bad?\nThe `dbg!` macro is intended as a debugging tool. It should not be present in released\nsoftware or committed to a version control system.\n\n### Example\n```rust\ndbg!(true)\n```\n\nUse instead:\n```rust\ntrue\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `allow-dbg-in-tests`: `bool`(defaults to `false`): Whether `dbg!` should be allowed in test functions or `#[cfg(test)]`\n", + "docs": "\n### What it does\nChecks for usage of the [`dbg!`](https://doc.rust-lang.org/std/macro.dbg.html) macro.\n\n### Why is this bad?\nThe `dbg!` macro is intended as a debugging tool. It should not be present in released\nsoftware or committed to a version control system.\n\n### Example\n```rust\ndbg!(true)\n```\n\nUse instead:\n```rust\ntrue\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `allow-dbg-in-tests`: Whether `dbg!` should be allowed in test functions or `#[cfg(test)]` (default: `false`)", "version": "1.34.0", "applicability": { "is_multi_part_suggestion": false, @@ -1196,7 +1196,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nWarns if there is a better representation for a numeric literal.\n\n### Why is this bad?\nEspecially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.\n\n### Example\n```text\n`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `literal-representation-threshold`: `u64`(defaults to `16384`): The lower bound for linting decimal literals\n", + "docs": "\n### What it does\nWarns if there is a better representation for a numeric literal.\n\n### Why is this bad?\nEspecially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.\n\n### Example\n```text\n`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `literal-representation-threshold`: The lower bound for linting decimal literals (default: `16384`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -1301,7 +1301,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\nChecks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.\n\n### Why is this bad?\nSince tool_attributes ([rust-lang/rust#44690](https://github.com/rust-lang/rust/issues/44690))\nare stable now, they should be used instead of the old `cfg_attr(rustfmt)` attributes.\n\n### Known problems\nThis lint doesn't detect crate level inner attributes, because they get\nprocessed before the PreExpansionPass lints get executed. See\n[#3123](https://github.com/rust-lang/rust-clippy/pull/3123#issuecomment-422321765)\n\n### Example\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nUse instead:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.\n\n### Why is this bad?\nSince tool_attributes ([rust-lang/rust#44690](https://github.com/rust-lang/rust/issues/44690))\nare stable now, they should be used instead of the old `cfg_attr(rustfmt)` attributes.\n\n### Known problems\nThis lint doesn't detect crate level inner attributes, because they get\nprocessed before the PreExpansionPass lints get executed. See\n[#3123](https://github.com/rust-lang/rust-clippy/pull/3123#issuecomment-422321765)\n\n### Example\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nUse instead:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.32.0", "applicability": { "is_multi_part_suggestion": false, @@ -1361,7 +1361,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\nDetects manual `std::default::Default` implementations that are identical to a derived implementation.\n\n### Why is this bad?\nIt is less concise.\n\n### Example\n```rust\nstruct Foo {\n bar: bool\n}\n\nimpl Default for Foo {\n fn default() -> Self {\n Self {\n bar: false\n }\n }\n}\n```\n\nUse instead:\n```rust\n#[derive(Default)]\nstruct Foo {\n bar: bool\n}\n```\n\n### Known problems\nDerive macros [sometimes use incorrect bounds](https://github.com/rust-lang/rust/issues/26925)\nin generic types and the user defined `impl` may be more generalized or\nspecialized than what derive will produce. This lint can't detect the manual `impl`\nhas exactly equal bounds, and therefore this lint is disabled for types with\ngeneric parameters.\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nDetects manual `std::default::Default` implementations that are identical to a derived implementation.\n\n### Why is this bad?\nIt is less concise.\n\n### Example\n```rust\nstruct Foo {\n bar: bool\n}\n\nimpl Default for Foo {\n fn default() -> Self {\n Self {\n bar: false\n }\n }\n}\n```\n\nUse instead:\n```rust\n#[derive(Default)]\nstruct Foo {\n bar: bool\n}\n```\n\n### Known problems\nDerive macros [sometimes use incorrect bounds](https://github.com/rust-lang/rust/issues/26925)\nin generic types and the user defined `impl` may be more generalized or\nspecialized than what derive will produce. This lint can't detect the manual `impl`\nhas exactly equal bounds, and therefore this lint is disabled for types with\ngeneric parameters.\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.57.0", "applicability": { "is_multi_part_suggestion": false, @@ -1420,11 +1420,11 @@ "id": "disallowed_macros", "id_span": { "path": "src/disallowed_macros.rs", - "line": 52 + "line": 51 }, "group": "style", "level": "warn", - "docs": "\n### What it does\nDenies the configured macros in clippy.toml\n\nNote: Even though this lint is warn-by-default, it will only trigger if\nmacros are defined in the clippy.toml file.\n\n### Why is this bad?\nSome macros are undesirable in certain contexts, and it's beneficial to\nlint for them as needed.\n\n### Example\nAn example clippy.toml configuration:\n```toml\n# clippy.toml\ndisallowed-macros = [\n # Can use a string as the path of the disallowed macro.\n \"std::print\",\n # Can also use an inline table with a `path` key.\n { path = \"std::println\" },\n # When using an inline table, can add a `reason` for why the macro\n # is disallowed.\n { path = \"serde::Serialize\", reason = \"no serializing\" },\n]\n```\n```rust\nuse serde::Serialize;\n\n// Example code where clippy issues a warning\nprintln!(\"warns\");\n\n// The diagnostic will contain the message \"no serializing\"\n#[derive(Serialize)]\nstruct Data {\n name: String,\n value: usize,\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `disallowed-macros`: `Vec`(defaults to `[]`): The list of disallowed macros, written as fully qualified paths.\n", + "docs": "\n### What it does\nDenies the configured macros in clippy.toml\n\nNote: Even though this lint is warn-by-default, it will only trigger if\nmacros are defined in the clippy.toml file.\n\n### Why is this bad?\nSome macros are undesirable in certain contexts, and it's beneficial to\nlint for them as needed.\n\n### Example\nAn example clippy.toml configuration:\n```toml\n# clippy.toml\ndisallowed-macros = [\n # Can use a string as the path of the disallowed macro.\n \"std::print\",\n # Can also use an inline table with a `path` key.\n { path = \"std::println\" },\n # When using an inline table, can add a `reason` for why the macro\n # is disallowed.\n { path = \"serde::Serialize\", reason = \"no serializing\" },\n]\n```\n```rust\nuse serde::Serialize;\n\n// Example code where clippy issues a warning\nprintln!(\"warns\");\n\n// The diagnostic will contain the message \"no serializing\"\n#[derive(Serialize)]\nstruct Data {\n name: String,\n value: usize,\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `disallowed-macros`: The list of disallowed macros, written as fully qualified paths. (default: `[]`)", "version": "1.66.0", "applicability": { "is_multi_part_suggestion": false, @@ -1435,11 +1435,11 @@ "id": "disallowed_methods", "id_span": { "path": "src/disallowed_methods.rs", - "line": 55 + "line": 53 }, "group": "style", "level": "warn", - "docs": "\n### What it does\nDenies the configured methods and functions in clippy.toml\n\nNote: Even though this lint is warn-by-default, it will only trigger if\nmethods are defined in the clippy.toml file.\n\n### Why is this bad?\nSome methods are undesirable in certain contexts, and it's beneficial to\nlint for them as needed.\n\n### Example\nAn example clippy.toml configuration:\n```toml\n# clippy.toml\ndisallowed-methods = [\n # Can use a string as the path of the disallowed method.\n \"std::boxed::Box::new\",\n # Can also use an inline table with a `path` key.\n { path = \"std::time::Instant::now\" },\n # When using an inline table, can add a `reason` for why the method\n # is disallowed.\n { path = \"std::vec::Vec::leak\", reason = \"no leaking memory\" },\n]\n```\n\n```rust\n// Example code where clippy issues a warning\nlet xs = vec![1, 2, 3, 4];\nxs.leak(); // Vec::leak is disallowed in the config.\n// The diagnostic contains the message \"no leaking memory\".\n\nlet _now = Instant::now(); // Instant::now is disallowed in the config.\n\nlet _box = Box::new(3); // Box::new is disallowed in the config.\n```\n\nUse instead:\n```rust\n// Example code which does not raise clippy warning\nlet mut xs = Vec::new(); // Vec::new is _not_ disallowed in the config.\nxs.push(123); // Vec::push is _not_ disallowed in the config.\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `disallowed-methods`: `Vec`(defaults to `[]`): The list of disallowed methods, written as fully qualified paths.\n\n### Past names\n\n* `disallowed_method`\n\n", + "docs": "\n### What it does\nDenies the configured methods and functions in clippy.toml\n\nNote: Even though this lint is warn-by-default, it will only trigger if\nmethods are defined in the clippy.toml file.\n\n### Why is this bad?\nSome methods are undesirable in certain contexts, and it's beneficial to\nlint for them as needed.\n\n### Example\nAn example clippy.toml configuration:\n```toml\n# clippy.toml\ndisallowed-methods = [\n # Can use a string as the path of the disallowed method.\n \"std::boxed::Box::new\",\n # Can also use an inline table with a `path` key.\n { path = \"std::time::Instant::now\" },\n # When using an inline table, can add a `reason` for why the method\n # is disallowed.\n { path = \"std::vec::Vec::leak\", reason = \"no leaking memory\" },\n]\n```\n\n```rust\n// Example code where clippy issues a warning\nlet xs = vec![1, 2, 3, 4];\nxs.leak(); // Vec::leak is disallowed in the config.\n// The diagnostic contains the message \"no leaking memory\".\n\nlet _now = Instant::now(); // Instant::now is disallowed in the config.\n\nlet _box = Box::new(3); // Box::new is disallowed in the config.\n```\n\nUse instead:\n```rust\n// Example code which does not raise clippy warning\nlet mut xs = Vec::new(); // Vec::new is _not_ disallowed in the config.\nxs.push(123); // Vec::push is _not_ disallowed in the config.\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `disallowed-methods`: The list of disallowed methods, written as fully qualified paths. (default: `[]`)\n### Past names\n\n* `disallowed_method`\n\n", "version": "1.49.0", "applicability": { "is_multi_part_suggestion": false, @@ -1457,7 +1457,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for usage of disallowed names for variables, such\nas `foo`.\n\n### Why is this bad?\nThese names are usually placeholder names and should be\navoided.\n\n### Example\n```rust\nlet foo = 3.14;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `disallowed-names`: `Vec`(defaults to `[\"foo\", \"baz\", \"quux\"]`): The list of disallowed names to lint about. NB: `bar` is not here since it has legitimate uses. The value\n `\"..\"` can be used as part of the list to indicate that the configured values should be appended to the\n default configuration of Clippy. By default, any configuration will replace the default value.\n\n### Past names\n\n* `blacklisted_name`\n\n", + "docs": "\n### What it does\nChecks for usage of disallowed names for variables, such\nas `foo`.\n\n### Why is this bad?\nThese names are usually placeholder names and should be\navoided.\n\n### Example\n```rust\nlet foo = 3.14;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `disallowed-names`: The list of disallowed names to lint about. NB: `bar` is not here since it has legitimate uses. The value\n `\"..\"` can be used as part of the list to indicate that the configured values should be appended to the\n default configuration of Clippy. By default, any configuration will replace the default value. (default: `[\"foo\", \"baz\", \"quux\"]`)\n### Past names\n\n* `blacklisted_name`\n\n", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -1475,7 +1475,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for usage of unicode scripts other than those explicitly allowed\nby the lint config.\n\nThis lint doesn't take into account non-text scripts such as `Unknown` and `Linear_A`.\nIt also ignores the `Common` script type.\nWhile configuring, be sure to use official script name [aliases] from\n[the list of supported scripts][supported_scripts].\n\nSee also: [`non_ascii_idents`].\n\n[aliases]: http://www.unicode.org/reports/tr24/tr24-31.html#Script_Value_Aliases\n[supported_scripts]: https://www.unicode.org/iso15924/iso15924-codes.html\n\n### Why is this bad?\nIt may be not desired to have many different scripts for\nidentifiers in the codebase.\n\nNote that if you only want to allow plain English, you might want to use\nbuilt-in [`non_ascii_idents`] lint instead.\n\n[`non_ascii_idents`]: https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#non-ascii-idents\n\n### Example\n```rust\n// Assuming that `clippy.toml` contains the following line:\n// allowed-scripts = [\"Latin\", \"Cyrillic\"]\nlet counter = 10; // OK, latin is allowed.\nlet счётчик = 10; // OK, cyrillic is allowed.\nlet zähler = 10; // OK, it's still latin.\nlet カウンタ = 10; // Will spawn the lint.\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `allowed-scripts`: `Vec`(defaults to `[\"Latin\"]`): The list of unicode scripts allowed to be used in the scope.\n", + "docs": "\n### What it does\nChecks for usage of unicode scripts other than those explicitly allowed\nby the lint config.\n\nThis lint doesn't take into account non-text scripts such as `Unknown` and `Linear_A`.\nIt also ignores the `Common` script type.\nWhile configuring, be sure to use official script name [aliases] from\n[the list of supported scripts][supported_scripts].\n\nSee also: [`non_ascii_idents`].\n\n[aliases]: http://www.unicode.org/reports/tr24/tr24-31.html#Script_Value_Aliases\n[supported_scripts]: https://www.unicode.org/iso15924/iso15924-codes.html\n\n### Why is this bad?\nIt may be not desired to have many different scripts for\nidentifiers in the codebase.\n\nNote that if you only want to allow plain English, you might want to use\nbuilt-in [`non_ascii_idents`] lint instead.\n\n[`non_ascii_idents`]: https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#non-ascii-idents\n\n### Example\n```rust\n// Assuming that `clippy.toml` contains the following line:\n// allowed-scripts = [\"Latin\", \"Cyrillic\"]\nlet counter = 10; // OK, latin is allowed.\nlet счётчик = 10; // OK, cyrillic is allowed.\nlet zähler = 10; // OK, it's still latin.\nlet カウンタ = 10; // Will spawn the lint.\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `allowed-scripts`: The list of unicode scripts allowed to be used in the scope. (default: `[\"Latin\"]`)", "version": "1.55.0", "applicability": { "is_multi_part_suggestion": false, @@ -1486,11 +1486,11 @@ "id": "disallowed_types", "id_span": { "path": "src/disallowed_types.rs", - "line": 49 + "line": 47 }, "group": "style", "level": "warn", - "docs": "\n### What it does\nDenies the configured types in clippy.toml.\n\nNote: Even though this lint is warn-by-default, it will only trigger if\ntypes are defined in the clippy.toml file.\n\n### Why is this bad?\nSome types are undesirable in certain contexts.\n\n### Example:\nAn example clippy.toml configuration:\n```toml\n# clippy.toml\ndisallowed-types = [\n # Can use a string as the path of the disallowed type.\n \"std::collections::BTreeMap\",\n # Can also use an inline table with a `path` key.\n { path = \"std::net::TcpListener\" },\n # When using an inline table, can add a `reason` for why the type\n # is disallowed.\n { path = \"std::net::Ipv4Addr\", reason = \"no IPv4 allowed\" },\n]\n```\n\n```rust\nuse std::collections::BTreeMap;\n// or its use\nlet x = std::collections::BTreeMap::new();\n```\nUse instead:\n```rust\n// A similar type that is allowed by the config\nuse std::collections::HashMap;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `disallowed-types`: `Vec`(defaults to `[]`): The list of disallowed types, written as fully qualified paths.\n\n### Past names\n\n* `disallowed_type`\n\n", + "docs": "\n### What it does\nDenies the configured types in clippy.toml.\n\nNote: Even though this lint is warn-by-default, it will only trigger if\ntypes are defined in the clippy.toml file.\n\n### Why is this bad?\nSome types are undesirable in certain contexts.\n\n### Example:\nAn example clippy.toml configuration:\n```toml\n# clippy.toml\ndisallowed-types = [\n # Can use a string as the path of the disallowed type.\n \"std::collections::BTreeMap\",\n # Can also use an inline table with a `path` key.\n { path = \"std::net::TcpListener\" },\n # When using an inline table, can add a `reason` for why the type\n # is disallowed.\n { path = \"std::net::Ipv4Addr\", reason = \"no IPv4 allowed\" },\n]\n```\n\n```rust\nuse std::collections::BTreeMap;\n// or its use\nlet x = std::collections::BTreeMap::new();\n```\nUse instead:\n```rust\n// A similar type that is allowed by the config\nuse std::collections::HashMap;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `disallowed-types`: The list of disallowed types, written as fully qualified paths. (default: `[]`)\n### Past names\n\n* `disallowed_type`\n\n", "version": "1.55.0", "applicability": { "is_multi_part_suggestion": false, @@ -1538,7 +1538,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.\n\n### Why is this bad?\n*Rustdoc* supports markdown formatting, `_`, `::` and\ncamel-case probably indicates some code which should be included between\nticks. `_` can also be used for emphasis in markdown, this lint tries to\nconsider that.\n\n### Known problems\nLots of bad docs won’t be fixed, what the lint checks\nfor is limited, and there are still false positives. HTML elements and their\ncontent are not linted.\n\nIn addition, when writing documentation comments, including `[]` brackets\ninside a link text would trip the parser. Therefore, documenting link with\n`[`SmallVec<[T; INLINE_CAPACITY]>`]` and then [`SmallVec<[T; INLINE_CAPACITY]>`]: SmallVec\nwould fail.\n\n### Examples\n```rust\n/// Do something with the foo_bar parameter. See also\n/// that::other::module::foo.\n// ^ `foo_bar` and `that::other::module::foo` should be ticked.\nfn doit(foo_bar: usize) {}\n```\n\n```rust\n// Link text with `[]` brackets should be written as following:\n/// Consume the array and return the inner\n/// [`SmallVec<[T; INLINE_CAPACITY]>`][SmallVec].\n/// [SmallVec]: SmallVec\nfn main() {}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `doc-valid-idents`: `Vec`(defaults to `[\"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\", \"DirectX\", \"ECMAScript\", \"GPLv2\", \"GPLv3\", \"GitHub\", \"GitLab\", \"IPv4\", \"IPv6\", \"ClojureScript\", \"CoffeeScript\", \"JavaScript\", \"PureScript\", \"TypeScript\", \"WebAssembly\", \"NaN\", \"NaNs\", \"OAuth\", \"GraphQL\", \"OCaml\", \"OpenGL\", \"OpenMP\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\", \"OpenDNS\", \"WebGL\", \"TensorFlow\", \"TrueType\", \"iOS\", \"macOS\", \"FreeBSD\", \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\", \"MinGW\", \"CamelCase\"]`): The list of words this lint should not consider as identifiers needing ticks. The value\n `\"..\"` can be used as part of the list to indicate, that the configured values should be appended to the\n default configuration of Clippy. By default, any configuration will replace the default value. For example:\n * `doc-valid-idents = [\"ClipPy\"]` would replace the default list with `[\"ClipPy\"]`.\n * `doc-valid-idents = [\"ClipPy\", \"..\"]` would append `ClipPy` to the default list.\n\n Default list:\n", + "docs": "\n### What it does\nChecks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.\n\n### Why is this bad?\n*Rustdoc* supports markdown formatting, `_`, `::` and\ncamel-case probably indicates some code which should be included between\nticks. `_` can also be used for emphasis in markdown, this lint tries to\nconsider that.\n\n### Known problems\nLots of bad docs won’t be fixed, what the lint checks\nfor is limited, and there are still false positives. HTML elements and their\ncontent are not linted.\n\nIn addition, when writing documentation comments, including `[]` brackets\ninside a link text would trip the parser. Therefore, documenting link with\n`[`SmallVec<[T; INLINE_CAPACITY]>`]` and then [`SmallVec<[T; INLINE_CAPACITY]>`]: SmallVec\nwould fail.\n\n### Examples\n```rust\n/// Do something with the foo_bar parameter. See also\n/// that::other::module::foo.\n// ^ `foo_bar` and `that::other::module::foo` should be ticked.\nfn doit(foo_bar: usize) {}\n```\n\n```rust\n// Link text with `[]` brackets should be written as following:\n/// Consume the array and return the inner\n/// [`SmallVec<[T; INLINE_CAPACITY]>`][SmallVec].\n/// [SmallVec]: SmallVec\nfn main() {}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `doc-valid-idents`: The list of words this lint should not consider as identifiers needing ticks. The value\n `\"..\"` can be used as part of the list to indicate, that the configured values should be appended to the\n default configuration of Clippy. By default, any configuration will replace the default value. For example:\n * `doc-valid-idents = [\"ClipPy\"]` would replace the default list with `[\"ClipPy\"]`.\n * `doc-valid-idents = [\"ClipPy\", \"..\"]` would append `ClipPy` to the default list. (default: `[\"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\", \"DirectX\", \"ECMAScript\", \"GPLv2\", \"GPLv3\", \"GitHub\", \"GitLab\", \"IPv4\", \"IPv6\", \"ClojureScript\", \"CoffeeScript\", \"JavaScript\", \"PureScript\", \"TypeScript\", \"WebAssembly\", \"NaN\", \"NaNs\", \"OAuth\", \"GraphQL\", \"OCaml\", \"OpenGL\", \"OpenMP\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\", \"OpenDNS\", \"WebGL\", \"TensorFlow\", \"TrueType\", \"iOS\", \"macOS\", \"FreeBSD\", \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\", \"MinGW\", \"CamelCase\"]`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -1823,7 +1823,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nDetects enumeration variants that are prefixed or suffixed\nby the same characters.\n\n### Why is this bad?\nEnumeration variant names should specify their variant,\nnot repeat the enumeration name.\n\n### Limitations\nCharacters with no casing will be considered when comparing prefixes/suffixes\nThis applies to numbers and non-ascii characters without casing\ne.g. `Foo1` and `Foo2` is considered to have different prefixes\n(the prefixes are `Foo1` and `Foo2` respectively), as also `Bar螃`, `Bar蟹`\n\n### Example\n```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```\nUse instead:\n```rust\nenum Cake {\n BlackForest,\n Hummingbird,\n Battenberg,\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n* `enum-variant-name-threshold`: `u64`(defaults to `3`): The minimum number of enum variants for the lints about variant names to trigger\n", + "docs": "\n### What it does\nDetects enumeration variants that are prefixed or suffixed\nby the same characters.\n\n### Why is this bad?\nEnumeration variant names should specify their variant,\nnot repeat the enumeration name.\n\n### Limitations\nCharacters with no casing will be considered when comparing prefixes/suffixes\nThis applies to numbers and non-ascii characters without casing\ne.g. `Foo1` and `Foo2` is considered to have different prefixes\n(the prefixes are `Foo1` and `Foo2` respectively), as also `Bar螃`, `Bar蟹`\n\n### Example\n```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```\nUse instead:\n```rust\nenum Cake {\n BlackForest,\n Hummingbird,\n Battenberg,\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)- `enum-variant-name-threshold`: The minimum number of enum variants for the lints about variant names to trigger (default: `3`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -1883,7 +1883,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for `.err().expect()` calls on the `Result` type.\n\n### Why is this bad?\n`.expect_err()` can be called directly to avoid the extra type conversion from `err()`.\n\n### Example\n```rust\nlet x: Result = Ok(10);\nx.err().expect(\"Testing err().expect()\");\n```\nUse instead:\n```rust\nlet x: Result = Ok(10);\nx.expect_err(\"Testing expect_err\");\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for `.err().expect()` calls on the `Result` type.\n\n### Why is this bad?\n`.expect_err()` can be called directly to avoid the extra type conversion from `err()`.\n\n### Example\n```rust\nlet x: Result = Ok(10);\nx.err().expect(\"Testing err().expect()\");\n```\nUse instead:\n```rust\nlet x: Result = Ok(10);\nx.expect_err(\"Testing expect_err\");\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.62.0", "applicability": { "is_multi_part_suggestion": false, @@ -1913,7 +1913,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\nChecks for blocks which are nested beyond a certain threshold.\n\nNote: Even though this lint is warn-by-default, it will only trigger if a maximum nesting level is defined in the clippy.toml file.\n\n### Why is this bad?\nIt can severely hinder readability.\n\n### Example\nAn example clippy.toml configuration:\n```toml\n# clippy.toml\nexcessive-nesting-threshold = 3\n```\n```rust\n// lib.rs\npub mod a {\n pub struct X;\n impl X {\n pub fn run(&self) {\n if true {\n // etc...\n }\n }\n }\n}\n```\nUse instead:\n```rust\n// a.rs\nfn private_run(x: &X) {\n if true {\n // etc...\n }\n}\n\npub struct X;\nimpl X {\n pub fn run(&self) {\n private_run(self);\n }\n}\n```\n```rust\n// lib.rs\npub mod a;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `excessive-nesting-threshold`: `u64`(defaults to `0`): The maximum amount of nesting a block can reside in\n", + "docs": "\n### What it does\nChecks for blocks which are nested beyond a certain threshold.\n\nNote: Even though this lint is warn-by-default, it will only trigger if a maximum nesting level is defined in the clippy.toml file.\n\n### Why is this bad?\nIt can severely hinder readability.\n\n### Example\nAn example clippy.toml configuration:\n```toml\n# clippy.toml\nexcessive-nesting-threshold = 3\n```\n```rust\n// lib.rs\npub mod a {\n pub struct X;\n impl X {\n pub fn run(&self) {\n if true {\n // etc...\n }\n }\n }\n}\n```\nUse instead:\n```rust\n// a.rs\nfn private_run(x: &X) {\n if true {\n // etc...\n }\n}\n\npub struct X;\nimpl X {\n pub fn run(&self) {\n private_run(self);\n }\n}\n```\n```rust\n// lib.rs\npub mod a;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `excessive-nesting-threshold`: The maximum amount of nesting a block can reside in (default: `0`)", "version": "1.72.0", "applicability": { "is_multi_part_suggestion": false, @@ -2003,7 +2003,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for `.expect()` or `.expect_err()` calls on `Result`s and `.expect()` call on `Option`s.\n\n### Why is this bad?\nUsually it is better to handle the `None` or `Err` case.\nStill, for a lot of quick-and-dirty code, `expect` is a good choice, which is why\nthis lint is `Allow` by default.\n\n`result.expect()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `?` operator.\n\n### Examples\n```rust\noption.expect(\"one\");\nresult.expect(\"one\");\n```\n\nUse instead:\n```rust\noption?;\n\n// or\n\nresult?;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `allow-expect-in-tests`: `bool`(defaults to `false`): Whether `expect` should be allowed in test functions or `#[cfg(test)]`\n\n### Past names\n\n* `option_expect_used`\n* `result_expect_used`\n\n", + "docs": "\n### What it does\nChecks for `.expect()` or `.expect_err()` calls on `Result`s and `.expect()` call on `Option`s.\n\n### Why is this bad?\nUsually it is better to handle the `None` or `Err` case.\nStill, for a lot of quick-and-dirty code, `expect` is a good choice, which is why\nthis lint is `Allow` by default.\n\n`result.expect()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `?` operator.\n\n### Examples\n```rust\noption.expect(\"one\");\nresult.expect(\"one\");\n```\n\nUse instead:\n```rust\noption?;\n\n// or\n\nresult?;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `allow-expect-in-tests`: Whether `expect` should be allowed in test functions or `#[cfg(test)]` (default: `false`)\n### Past names\n\n* `option_expect_used`\n* `result_expect_used`\n\n", "version": "1.45.0", "applicability": { "is_multi_part_suggestion": false, @@ -2277,7 +2277,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for usage of `_.filter_map(_).next()`.\n\n### Why is this bad?\nReadability, this can be written more concisely as\n`_.find_map(_)`.\n\n### Example\n```rust\n (0..3).filter_map(|x| if x == 2 { Some(x) } else { None }).next();\n```\nCan be written as\n\n```rust\n (0..3).find_map(|x| if x == 2 { Some(x) } else { None });\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for usage of `_.filter_map(_).next()`.\n\n### Why is this bad?\nReadability, this can be written more concisely as\n`_.find_map(_)`.\n\n### Example\n```rust\n (0..3).filter_map(|x| if x == 2 { Some(x) } else { None }).next();\n```\nCan be written as\n\n```rust\n (0..3).find_map(|x| if x == 2 { Some(x) } else { None });\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.36.0", "applicability": { "is_multi_part_suggestion": false, @@ -2427,7 +2427,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for excessive use of\nbools in function definitions.\n\n### Why is this bad?\nCalls to such functions\nare confusing and error prone, because it's\nhard to remember argument order and you have\nno type system support to back you up. Using\ntwo-variant enums instead of bools often makes\nAPI easier to use.\n\n### Example\n```rust\nfn f(is_round: bool, is_hot: bool) { ... }\n```\n\nUse instead:\n```rust\nenum Shape {\n Round,\n Spiky,\n}\n\nenum Temperature {\n Hot,\n IceCold,\n}\n\nfn f(shape: Shape, temperature: Temperature) { ... }\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `max-fn-params-bools`: `u64`(defaults to `3`): The maximum number of bool parameters a function can have\n", + "docs": "\n### What it does\nChecks for excessive use of\nbools in function definitions.\n\n### Why is this bad?\nCalls to such functions\nare confusing and error prone, because it's\nhard to remember argument order and you have\nno type system support to back you up. Using\ntwo-variant enums instead of bools often makes\nAPI easier to use.\n\n### Example\n```rust\nfn f(is_round: bool, is_hot: bool) { ... }\n```\n\nUse instead:\n```rust\nenum Shape {\n Round,\n Spiky,\n}\n\nenum Temperature {\n Hot,\n IceCold,\n}\n\nfn f(shape: Shape, temperature: Temperature) { ... }\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `max-fn-params-bools`: The maximum number of bool parameters a function can have (default: `3`)", "version": "1.43.0", "applicability": { "is_multi_part_suggestion": false, @@ -2592,7 +2592,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nSearches for implementations of the `Into<..>` trait and suggests to implement `From<..>` instead.\n\n### Why is this bad?\nAccording the std docs implementing `From<..>` is preferred since it gives you `Into<..>` for free where the reverse isn't true.\n\n### Example\n```rust\nstruct StringWrapper(String);\n\nimpl Into for String {\n fn into(self) -> StringWrapper {\n StringWrapper(self)\n }\n}\n```\nUse instead:\n```rust\nstruct StringWrapper(String);\n\nimpl From for StringWrapper {\n fn from(s: String) -> StringWrapper {\n StringWrapper(s)\n }\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nSearches for implementations of the `Into<..>` trait and suggests to implement `From<..>` instead.\n\n### Why is this bad?\nAccording the std docs implementing `From<..>` is preferred since it gives you `Into<..>` for free where the reverse isn't true.\n\n### Example\n```rust\nstruct StringWrapper(String);\n\nimpl Into for String {\n fn into(self) -> StringWrapper {\n StringWrapper(self)\n }\n}\n```\nUse instead:\n```rust\nstruct StringWrapper(String);\n\nimpl From for StringWrapper {\n fn from(s: String) -> StringWrapper {\n StringWrapper(s)\n }\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.51.0", "applicability": { "is_multi_part_suggestion": false, @@ -2787,7 +2787,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for if-else that could be written using either `bool::then` or `bool::then_some`.\n\n### Why is this bad?\nLooks a little redundant. Using `bool::then` is more concise and incurs no loss of clarity.\nFor simple calculations and known values, use `bool::then_some`, which is eagerly evaluated\nin comparison to `bool::then`.\n\n### Example\n```rust\nlet a = if v.is_empty() {\n println!(\"true!\");\n Some(42)\n} else {\n None\n};\n```\n\nCould be written:\n\n```rust\nlet a = v.is_empty().then(|| {\n println!(\"true!\");\n 42\n});\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for if-else that could be written using either `bool::then` or `bool::then_some`.\n\n### Why is this bad?\nLooks a little redundant. Using `bool::then` is more concise and incurs no loss of clarity.\nFor simple calculations and known values, use `bool::then_some`, which is eagerly evaluated\nin comparison to `bool::then`.\n\n### Example\n```rust\nlet a = if v.is_empty() {\n println!(\"true!\");\n Some(42)\n} else {\n None\n};\n```\n\nCould be written:\n\n```rust\nlet a = v.is_empty().then(|| {\n println!(\"true!\");\n 42\n});\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.53.0", "applicability": { "is_multi_part_suggestion": false, @@ -2802,7 +2802,7 @@ }, "group": "correctness", "level": "deny", - "docs": "\n### What it does\nChecks for consecutive `if`s with the same condition.\n\n### Why is this bad?\nThis is probably a copy & paste error.\n\n### Example\n```rust\nif a == b {\n …\n} else if a == b {\n …\n}\n```\n\nNote that this lint ignores all conditions with a function call as it could\nhave side effects:\n\n```rust\nif foo() {\n …\n} else if foo() { // not linted\n …\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `ignore-interior-mutability`: `Vec`(defaults to `[\"bytes::Bytes\"]`): A list of paths to types that should be treated like `Arc`, i.e. ignored but\n for the generic parameters for determining interior mutability\n", + "docs": "\n### What it does\nChecks for consecutive `if`s with the same condition.\n\n### Why is this bad?\nThis is probably a copy & paste error.\n\n### Example\n```rust\nif a == b {\n …\n} else if a == b {\n …\n}\n```\n\nNote that this lint ignores all conditions with a function call as it could\nhave side effects:\n\n```rust\nif foo() {\n …\n} else if foo() { // not linted\n …\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `ignore-interior-mutability`: A list of paths to types that should be treated like `Arc`, i.e. ignored but\n for the generic parameters for determining interior mutability (default: `[\"bytes::Bytes\"]`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -2997,7 +2997,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nThe lint checks for slice bindings in patterns that are only used to\naccess individual slice values.\n\n### Why is this bad?\nAccessing slice values using indices can lead to panics. Using refutable\npatterns can avoid these. Binding to individual values also improves the\nreadability as they can be named.\n\n### Limitations\nThis lint currently only checks for immutable access inside `if let`\npatterns.\n\n### Example\n```rust\nlet slice: Option<&[u32]> = Some(&[1, 2, 3]);\n\nif let Some(slice) = slice {\n println!(\"{}\", slice[0]);\n}\n```\nUse instead:\n```rust\nlet slice: Option<&[u32]> = Some(&[1, 2, 3]);\n\nif let Some(&[first, ..]) = slice {\n println!(\"{}\", first);\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n* `max-suggested-slice-pattern-length`: `u64`(defaults to `3`): When Clippy suggests using a slice pattern, this is the maximum number of elements allowed in\n the slice pattern that is suggested. If more elements are necessary, the lint is suppressed.\n For example, `[_, _, _, e, ..]` is a slice pattern with 4 elements.\n", + "docs": "\n### What it does\nThe lint checks for slice bindings in patterns that are only used to\naccess individual slice values.\n\n### Why is this bad?\nAccessing slice values using indices can lead to panics. Using refutable\npatterns can avoid these. Binding to individual values also improves the\nreadability as they can be named.\n\n### Limitations\nThis lint currently only checks for immutable access inside `if let`\npatterns.\n\n### Example\n```rust\nlet slice: Option<&[u32]> = Some(&[1, 2, 3]);\n\nif let Some(slice) = slice {\n println!(\"{}\", slice[0]);\n}\n```\nUse instead:\n```rust\nlet slice: Option<&[u32]> = Some(&[1, 2, 3]);\n\nif let Some(&[first, ..]) = slice {\n println!(\"{}\", first);\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`- `max-suggested-slice-pattern-length`: When Clippy suggests using a slice pattern, this is the maximum number of elements allowed in\n the slice pattern that is suggested. If more elements are necessary, the lint is suppressed.\n For example, `[_, _, _, e, ..]` is a slice pattern with 4 elements. (default: `3`)", "version": "1.59.0", "applicability": { "is_multi_part_suggestion": false, @@ -3012,7 +3012,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for usage of indexing or slicing. Arrays are special cases, this lint\ndoes report on arrays if we can tell that slicing operations are in bounds and does not\nlint on constant `usize` indexing on arrays because that is handled by rustc's `const_err` lint.\n\n### Why is this bad?\nIndexing and slicing can panic at runtime and there are\nsafe alternatives.\n\n### Example\n```rust\n// Vector\nlet x = vec![0; 5];\n\nx[2];\n&x[2..100];\n\n// Array\nlet y = [0, 1, 2, 3];\n\n&y[10..100];\n&y[10..];\n```\n\nUse instead:\n```rust\n\nx.get(2);\nx.get(2..100);\n\ny.get(10);\ny.get(10..100);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `suppress-restriction-lint-in-const`: `bool`(defaults to `false`): Whether to suppress a restriction lint in constant code. In same\n cases the restructured operation might not be unavoidable, as the\n suggested counterparts are unavailable in constant code. This\n configuration will cause restriction lints to trigger even\n if no suggestion can be made.\n", + "docs": "\n### What it does\nChecks for usage of indexing or slicing. Arrays are special cases, this lint\ndoes report on arrays if we can tell that slicing operations are in bounds and does not\nlint on constant `usize` indexing on arrays because that is handled by rustc's `const_err` lint.\n\n### Why is this bad?\nIndexing and slicing can panic at runtime and there are\nsafe alternatives.\n\n### Example\n```rust\n// Vector\nlet x = vec![0; 5];\n\nx[2];\n&x[2..100];\n\n// Array\nlet y = [0, 1, 2, 3];\n\n&y[10..100];\n&y[10..];\n```\n\nUse instead:\n```rust\n\nx.get(2);\nx.get(2..100);\n\ny.get(10);\ny.get(10..100);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `suppress-restriction-lint-in-const`: Whether to suppress a restriction lint in constant code. In same\n cases the restructured operation might not be unavoidable, as the\n suggested counterparts are unavailable in constant code. This\n configuration will cause restriction lints to trigger even\n if no suggestion can be made. (default: `false`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -3645,7 +3645,7 @@ }, "group": "perf", "level": "warn", - "docs": "\n### What it does\nChecks for large `const` arrays that should\nbe defined as `static` instead.\n\n### Why is this bad?\nPerformance: const variables are inlined upon use.\nStatic items result in only one instance and has a fixed location in memory.\n\n### Example\n```rust\npub const a = [0u32; 1_000_000];\n```\n\nUse instead:\n```rust\npub static a = [0u32; 1_000_000];\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `array-size-threshold`: `u64`(defaults to `512000`): The maximum allowed size for arrays on the stack\n", + "docs": "\n### What it does\nChecks for large `const` arrays that should\nbe defined as `static` instead.\n\n### Why is this bad?\nPerformance: const variables are inlined upon use.\nStatic items result in only one instance and has a fixed location in memory.\n\n### Example\n```rust\npub const a = [0u32; 1_000_000];\n```\n\nUse instead:\n```rust\npub static a = [0u32; 1_000_000];\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `array-size-threshold`: The maximum allowed size for arrays on the stack (default: `512000`)", "version": "1.44.0", "applicability": { "is_multi_part_suggestion": false, @@ -3675,7 +3675,7 @@ }, "group": "perf", "level": "warn", - "docs": "\n### What it does\nChecks for large size differences between variants on\n`enum`s.\n\n### Why is this bad?\nEnum size is bounded by the largest variant. Having one\nlarge variant can penalize the memory layout of that enum.\n\n### Known problems\nThis lint obviously cannot take the distribution of\nvariants in your running program into account. It is possible that the\nsmaller variants make up less than 1% of all instances, in which case\nthe overhead is negligible and the boxing is counter-productive. Always\nmeasure the change this lint suggests.\n\nFor types that implement `Copy`, the suggestion to `Box` a variant's\ndata would require removing the trait impl. The types can of course\nstill be `Clone`, but that is worse ergonomically. Depending on the\nuse case it may be possible to store the large data in an auxiliary\nstructure (e.g. Arena or ECS).\n\nThe lint will ignore the impact of generic types to the type layout by\nassuming every type parameter is zero-sized. Depending on your use case,\nthis may lead to a false positive.\n\n### Example\n```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```\n\nUse instead:\n```rust\n// Possibly better\nenum Test2 {\n A(i32),\n B(Box<[i32; 8000]>),\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `enum-variant-size-threshold`: `u64`(defaults to `200`): The maximum size of an enum's variant to avoid box suggestion\n", + "docs": "\n### What it does\nChecks for large size differences between variants on\n`enum`s.\n\n### Why is this bad?\nEnum size is bounded by the largest variant. Having one\nlarge variant can penalize the memory layout of that enum.\n\n### Known problems\nThis lint obviously cannot take the distribution of\nvariants in your running program into account. It is possible that the\nsmaller variants make up less than 1% of all instances, in which case\nthe overhead is negligible and the boxing is counter-productive. Always\nmeasure the change this lint suggests.\n\nFor types that implement `Copy`, the suggestion to `Box` a variant's\ndata would require removing the trait impl. The types can of course\nstill be `Clone`, but that is worse ergonomically. Depending on the\nuse case it may be possible to store the large data in an auxiliary\nstructure (e.g. Arena or ECS).\n\nThe lint will ignore the impact of generic types to the type layout by\nassuming every type parameter is zero-sized. Depending on your use case,\nthis may lead to a false positive.\n\n### Example\n```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```\n\nUse instead:\n```rust\n// Possibly better\nenum Test2 {\n A(i32),\n B(Box<[i32; 8000]>),\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `enum-variant-size-threshold`: The maximum size of an enum's variant to avoid box suggestion (default: `200`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -3690,7 +3690,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nIt checks for the size of a `Future` created by `async fn` or `async {}`.\n\n### Why is this bad?\nDue to the current [unideal implementation](https://github.com/rust-lang/rust/issues/69826) of `Coroutine`,\nlarge size of a `Future` may cause stack overflows.\n\n### Example\n```rust\nasync fn large_future(_x: [u8; 16 * 1024]) {}\n\npub async fn trigger() {\n large_future([0u8; 16 * 1024]).await;\n}\n```\n\n`Box::pin` the big future instead.\n\n```rust\nasync fn large_future(_x: [u8; 16 * 1024]) {}\n\npub async fn trigger() {\n Box::pin(large_future([0u8; 16 * 1024])).await;\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `future-size-threshold`: `u64`(defaults to `16384`): The maximum byte size a `Future` can have, before it triggers the `clippy::large_futures` lint\n", + "docs": "\n### What it does\nIt checks for the size of a `Future` created by `async fn` or `async {}`.\n\n### Why is this bad?\nDue to the current [unideal implementation](https://github.com/rust-lang/rust/issues/69826) of `Coroutine`,\nlarge size of a `Future` may cause stack overflows.\n\n### Example\n```rust\nasync fn large_future(_x: [u8; 16 * 1024]) {}\n\npub async fn trigger() {\n large_future([0u8; 16 * 1024]).await;\n}\n```\n\n`Box::pin` the big future instead.\n\n```rust\nasync fn large_future(_x: [u8; 16 * 1024]) {}\n\npub async fn trigger() {\n Box::pin(large_future([0u8; 16 * 1024])).await;\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `future-size-threshold`: The maximum byte size a `Future` can have, before it triggers the `clippy::large_futures` lint (default: `16384`)", "version": "1.70.0", "applicability": { "is_multi_part_suggestion": false, @@ -3705,7 +3705,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for the inclusion of large files via `include_bytes!()`\nand `include_str!()`\n\n### Why is this bad?\nIncluding large files can increase the size of the binary\n\n### Example\n```rust\nlet included_str = include_str!(\"very_large_file.txt\");\nlet included_bytes = include_bytes!(\"very_large_file.txt\");\n```\n\nUse instead:\n```rust\nuse std::fs;\n\n// You can load the file at runtime\nlet string = fs::read_to_string(\"very_large_file.txt\")?;\nlet bytes = fs::read(\"very_large_file.txt\")?;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `max-include-file-size`: `u64`(defaults to `1000000`): The maximum size of a file included via `include_bytes!()` or `include_str!()`, in bytes\n", + "docs": "\n### What it does\nChecks for the inclusion of large files via `include_bytes!()`\nand `include_str!()`\n\n### Why is this bad?\nIncluding large files can increase the size of the binary\n\n### Example\n```rust\nlet included_str = include_str!(\"very_large_file.txt\");\nlet included_bytes = include_bytes!(\"very_large_file.txt\");\n```\n\nUse instead:\n```rust\nuse std::fs;\n\n// You can load the file at runtime\nlet string = fs::read_to_string(\"very_large_file.txt\")?;\nlet bytes = fs::read(\"very_large_file.txt\")?;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `max-include-file-size`: The maximum size of a file included via `include_bytes!()` or `include_str!()`, in bytes (default: `1000000`)", "version": "1.62.0", "applicability": { "is_multi_part_suggestion": false, @@ -3720,7 +3720,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for local arrays that may be too large.\n\n### Why is this bad?\nLarge local arrays may cause stack overflow.\n\n### Example\n```rust\nlet a = [0u32; 1_000_000];\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `array-size-threshold`: `u64`(defaults to `512000`): The maximum allowed size for arrays on the stack\n", + "docs": "\n### What it does\nChecks for local arrays that may be too large.\n\n### Why is this bad?\nLarge local arrays may cause stack overflow.\n\n### Example\n```rust\nlet a = [0u32; 1_000_000];\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `array-size-threshold`: The maximum allowed size for arrays on the stack (default: `512000`)", "version": "1.41.0", "applicability": { "is_multi_part_suggestion": false, @@ -3735,7 +3735,7 @@ }, "group": "nursery", "level": "allow", - "docs": "\n### What it does\nChecks for functions that use a lot of stack space.\n\nThis often happens when constructing a large type, such as an array with a lot of elements,\nor constructing *many* smaller-but-still-large structs, or copying around a lot of large types.\n\nThis lint is a more general version of [`large_stack_arrays`](https://rust-lang.github.io/rust-clippy/master/#large_stack_arrays)\nthat is intended to look at functions as a whole instead of only individual array expressions inside of a function.\n\n### Why is this bad?\nThe stack region of memory is very limited in size (usually *much* smaller than the heap) and attempting to\nuse too much will result in a stack overflow and crash the program.\nTo avoid this, you should consider allocating large types on the heap instead (e.g. by boxing them).\n\nKeep in mind that the code path to construction of large types does not even need to be reachable;\nit purely needs to *exist* inside of the function to contribute to the stack size.\nFor example, this causes a stack overflow even though the branch is unreachable:\n```rust\nfn main() {\n if false {\n let x = [0u8; 10000000]; // 10 MB stack array\n black_box(&x);\n }\n}\n```\n\n### Known issues\nFalse positives. The stack size that clippy sees is an estimated value and can be vastly different\nfrom the actual stack usage after optimizations passes have run (especially true in release mode).\nModern compilers are very smart and are able to optimize away a lot of unnecessary stack allocations.\nIn debug mode however, it is usually more accurate.\n\nThis lint works by summing up the size of all variables that the user typed, variables that were\nimplicitly introduced by the compiler for temporaries, function arguments and the return value,\nand comparing them against a (configurable, but high-by-default).\n\n### Example\nThis function creates four 500 KB arrays on the stack. Quite big but just small enough to not trigger `large_stack_arrays`.\nHowever, looking at the function as a whole, it's clear that this uses a lot of stack space.\n```rust\nstruct QuiteLargeType([u8; 500_000]);\nfn foo() {\n // ... some function that uses a lot of stack space ...\n let _x1 = QuiteLargeType([0; 500_000]);\n let _x2 = QuiteLargeType([0; 500_000]);\n let _x3 = QuiteLargeType([0; 500_000]);\n let _x4 = QuiteLargeType([0; 500_000]);\n}\n```\n\nInstead of doing this, allocate the arrays on the heap.\nThis currently requires going through a `Vec` first and then converting it to a `Box`:\n```rust\nstruct NotSoLargeType(Box<[u8]>);\n\nfn foo() {\n let _x1 = NotSoLargeType(vec![0; 500_000].into_boxed_slice());\n// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Now heap allocated.\n// The size of `NotSoLargeType` is 16 bytes.\n// ...\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `stack-size-threshold`: `u64`(defaults to `512000`): The maximum allowed stack size for functions in bytes\n", + "docs": "\n### What it does\nChecks for functions that use a lot of stack space.\n\nThis often happens when constructing a large type, such as an array with a lot of elements,\nor constructing *many* smaller-but-still-large structs, or copying around a lot of large types.\n\nThis lint is a more general version of [`large_stack_arrays`](https://rust-lang.github.io/rust-clippy/master/#large_stack_arrays)\nthat is intended to look at functions as a whole instead of only individual array expressions inside of a function.\n\n### Why is this bad?\nThe stack region of memory is very limited in size (usually *much* smaller than the heap) and attempting to\nuse too much will result in a stack overflow and crash the program.\nTo avoid this, you should consider allocating large types on the heap instead (e.g. by boxing them).\n\nKeep in mind that the code path to construction of large types does not even need to be reachable;\nit purely needs to *exist* inside of the function to contribute to the stack size.\nFor example, this causes a stack overflow even though the branch is unreachable:\n```rust\nfn main() {\n if false {\n let x = [0u8; 10000000]; // 10 MB stack array\n black_box(&x);\n }\n}\n```\n\n### Known issues\nFalse positives. The stack size that clippy sees is an estimated value and can be vastly different\nfrom the actual stack usage after optimizations passes have run (especially true in release mode).\nModern compilers are very smart and are able to optimize away a lot of unnecessary stack allocations.\nIn debug mode however, it is usually more accurate.\n\nThis lint works by summing up the size of all variables that the user typed, variables that were\nimplicitly introduced by the compiler for temporaries, function arguments and the return value,\nand comparing them against a (configurable, but high-by-default).\n\n### Example\nThis function creates four 500 KB arrays on the stack. Quite big but just small enough to not trigger `large_stack_arrays`.\nHowever, looking at the function as a whole, it's clear that this uses a lot of stack space.\n```rust\nstruct QuiteLargeType([u8; 500_000]);\nfn foo() {\n // ... some function that uses a lot of stack space ...\n let _x1 = QuiteLargeType([0; 500_000]);\n let _x2 = QuiteLargeType([0; 500_000]);\n let _x3 = QuiteLargeType([0; 500_000]);\n let _x4 = QuiteLargeType([0; 500_000]);\n}\n```\n\nInstead of doing this, allocate the arrays on the heap.\nThis currently requires going through a `Vec` first and then converting it to a `Box`:\n```rust\nstruct NotSoLargeType(Box<[u8]>);\n\nfn foo() {\n let _x1 = NotSoLargeType(vec![0; 500_000].into_boxed_slice());\n// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Now heap allocated.\n// The size of `NotSoLargeType` is 16 bytes.\n// ...\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `stack-size-threshold`: The maximum allowed stack size for functions in bytes (default: `512000`)", "version": "1.72.0", "applicability": { "is_multi_part_suggestion": false, @@ -3750,7 +3750,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for functions taking arguments by value, where\nthe argument type is `Copy` and large enough to be worth considering\npassing by reference. Does not trigger if the function is being exported,\nbecause that might induce API breakage, if the parameter is declared as mutable,\nor if the argument is a `self`.\n\n### Why is this bad?\nArguments passed by value might result in an unnecessary\nshallow copy, taking up more space in the stack and requiring a call to\n`memcpy`, which can be expensive.\n\n### Example\n```rust\n#[derive(Clone, Copy)]\nstruct TooLarge([u8; 2048]);\n\nfn foo(v: TooLarge) {}\n```\n\nUse instead:\n```rust\nfn foo(v: &TooLarge) {}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n* `pass-by-value-size-limit`: `u64`(defaults to `256`): The minimum size (in bytes) to consider a type for passing by reference instead of by value.\n", + "docs": "\n### What it does\nChecks for functions taking arguments by value, where\nthe argument type is `Copy` and large enough to be worth considering\npassing by reference. Does not trigger if the function is being exported,\nbecause that might induce API breakage, if the parameter is declared as mutable,\nor if the argument is a `self`.\n\n### Why is this bad?\nArguments passed by value might result in an unnecessary\nshallow copy, taking up more space in the stack and requiring a call to\n`memcpy`, which can be expensive.\n\n### Example\n```rust\n#[derive(Clone, Copy)]\nstruct TooLarge([u8; 2048]);\n\nfn foo(v: TooLarge) {}\n```\n\nUse instead:\n```rust\nfn foo(v: &TooLarge) {}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)- `pass-by-value-size-limit`: The minimum size (in bytes) to consider a type for passing by reference instead of by value. (default: `256`)", "version": "1.49.0", "applicability": { "is_multi_part_suggestion": false, @@ -3915,7 +3915,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).\n\n### Why is this bad?\nGankra says:\n\n> The TL;DR of `LinkedList` is that it's built on a massive amount of\npointers and indirection.\n> It wastes memory, it has terrible cache locality, and is all-around slow.\n`RingBuf`, while\n> \"only\" amortized for push/pop, should be faster in the general case for\nalmost every possible\n> workload, and isn't even amortized at all if you can predict the capacity\nyou need.\n>\n> `LinkedList`s are only really good if you're doing a lot of merging or\nsplitting of lists.\n> This is because they can just mangle some pointers instead of actually\ncopying the data. Even\n> if you're doing a lot of insertion in the middle of the list, `RingBuf`\ncan still be better\n> because of how expensive it is to seek to the middle of a `LinkedList`.\n\n### Known problems\nFalse positives – the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.\n\n### Example\n```rust\nlet x: LinkedList = LinkedList::new();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n", + "docs": "\n### What it does\nChecks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).\n\n### Why is this bad?\nGankra says:\n\n> The TL;DR of `LinkedList` is that it's built on a massive amount of\npointers and indirection.\n> It wastes memory, it has terrible cache locality, and is all-around slow.\n`RingBuf`, while\n> \"only\" amortized for push/pop, should be faster in the general case for\nalmost every possible\n> workload, and isn't even amortized at all if you can predict the capacity\nyou need.\n>\n> `LinkedList`s are only really good if you're doing a lot of merging or\nsplitting of lists.\n> This is because they can just mangle some pointers instead of actually\ncopying the data. Even\n> if you're doing a lot of insertion in the middle of the list, `RingBuf`\ncan still be better\n> because of how expensive it is to seek to the middle of a `LinkedList`.\n\n### Known problems\nFalse positives – the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.\n\n### Example\n```rust\nlet x: LinkedList = LinkedList::new();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -4020,7 +4020,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for usage of `std::mem::size_of::() * 8` when\n`T::BITS` is available.\n\n### Why is this bad?\nCan be written as the shorter `T::BITS`.\n\n### Example\n```rust\nstd::mem::size_of::() * 8;\n```\nUse instead:\n```rust\nusize::BITS as usize;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for usage of `std::mem::size_of::() * 8` when\n`T::BITS` is available.\n\n### Why is this bad?\nCan be written as the shorter `T::BITS`.\n\n### Example\n```rust\nstd::mem::size_of::() * 8;\n```\nUse instead:\n```rust\nusize::BITS as usize;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.60.0", "applicability": { "is_multi_part_suggestion": false, @@ -4035,7 +4035,7 @@ }, "group": "nursery", "level": "allow", - "docs": "\n### What it does\nIdentifies good opportunities for a clamp function from std or core, and suggests using it.\n\n### Why is this bad?\nclamp is much shorter, easier to read, and doesn't use any control flow.\n\n### Known issue(s)\nIf the clamped variable is NaN this suggestion will cause the code to propagate NaN\nrather than returning either `max` or `min`.\n\n`clamp` functions will panic if `max < min`, `max.is_nan()`, or `min.is_nan()`.\nSome may consider panicking in these situations to be desirable, but it also may\nintroduce panicking where there wasn't any before.\n\nSee also [the discussion in the\nPR](https://github.com/rust-lang/rust-clippy/pull/9484#issuecomment-1278922613).\n\n### Examples\n```rust\nif input > max {\n max\n} else if input < min {\n min\n} else {\n input\n}\n```\n\n```rust\ninput.max(min).min(max)\n```\n\n```rust\nmatch input {\n x if x > max => max,\n x if x < min => min,\n x => x,\n}\n```\n\n```rust\nlet mut x = input;\nif x < min { x = min; }\nif x > max { x = max; }\n```\nUse instead:\n```rust\ninput.clamp(min, max)\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nIdentifies good opportunities for a clamp function from std or core, and suggests using it.\n\n### Why is this bad?\nclamp is much shorter, easier to read, and doesn't use any control flow.\n\n### Known issue(s)\nIf the clamped variable is NaN this suggestion will cause the code to propagate NaN\nrather than returning either `max` or `min`.\n\n`clamp` functions will panic if `max < min`, `max.is_nan()`, or `min.is_nan()`.\nSome may consider panicking in these situations to be desirable, but it also may\nintroduce panicking where there wasn't any before.\n\nSee also [the discussion in the\nPR](https://github.com/rust-lang/rust-clippy/pull/9484#issuecomment-1278922613).\n\n### Examples\n```rust\nif input > max {\n max\n} else if input < min {\n min\n} else {\n input\n}\n```\n\n```rust\ninput.max(min).min(max)\n```\n\n```rust\nmatch input {\n x if x > max => max,\n x if x < min => min,\n x => x,\n}\n```\n\n```rust\nlet mut x = input;\nif x < min { x = min; }\nif x > max { x = max; }\n```\nUse instead:\n```rust\ninput.clamp(min, max)\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.66.0", "applicability": { "is_multi_part_suggestion": false, @@ -4125,7 +4125,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\nChecks for cases where [`BuildHasher::hash_one`] can be used.\n\n[`BuildHasher::hash_one`]: https://doc.rust-lang.org/std/hash/trait.BuildHasher.html#method.hash_one\n\n### Why is this bad?\nIt is more concise to use the `hash_one` method.\n\n### Example\n```rust\nuse std::hash::{BuildHasher, Hash, Hasher};\nuse std::collections::hash_map::RandomState;\n\nlet s = RandomState::new();\nlet value = vec![1, 2, 3];\n\nlet mut hasher = s.build_hasher();\nvalue.hash(&mut hasher);\nlet hash = hasher.finish();\n```\nUse instead:\n```rust\nuse std::hash::BuildHasher;\nuse std::collections::hash_map::RandomState;\n\nlet s = RandomState::new();\nlet value = vec![1, 2, 3];\n\nlet hash = s.hash_one(&value);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for cases where [`BuildHasher::hash_one`] can be used.\n\n[`BuildHasher::hash_one`]: https://doc.rust-lang.org/std/hash/trait.BuildHasher.html#method.hash_one\n\n### Why is this bad?\nIt is more concise to use the `hash_one` method.\n\n### Example\n```rust\nuse std::hash::{BuildHasher, Hash, Hasher};\nuse std::collections::hash_map::RandomState;\n\nlet s = RandomState::new();\nlet value = vec![1, 2, 3];\n\nlet mut hasher = s.build_hasher();\nvalue.hash(&mut hasher);\nlet hash = hasher.finish();\n```\nUse instead:\n```rust\nuse std::hash::BuildHasher;\nuse std::collections::hash_map::RandomState;\n\nlet s = RandomState::new();\nlet value = vec![1, 2, 3];\n\nlet hash = s.hash_one(&value);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.74.0", "applicability": { "is_multi_part_suggestion": false, @@ -4155,7 +4155,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nSuggests to use dedicated built-in methods,\n`is_ascii_(lowercase|uppercase|digit|hexdigit)` for checking on corresponding\nascii range\n\n### Why is this bad?\nUsing the built-in functions is more readable and makes it\nclear that it's not a specific subset of characters, but all\nASCII (lowercase|uppercase|digit|hexdigit) characters.\n### Example\n```rust\nfn main() {\n assert!(matches!('x', 'a'..='z'));\n assert!(matches!(b'X', b'A'..=b'Z'));\n assert!(matches!('2', '0'..='9'));\n assert!(matches!('x', 'A'..='Z' | 'a'..='z'));\n assert!(matches!('C', '0'..='9' | 'a'..='f' | 'A'..='F'));\n\n ('0'..='9').contains(&'0');\n ('a'..='z').contains(&'a');\n ('A'..='Z').contains(&'A');\n}\n```\nUse instead:\n```rust\nfn main() {\n assert!('x'.is_ascii_lowercase());\n assert!(b'X'.is_ascii_uppercase());\n assert!('2'.is_ascii_digit());\n assert!('x'.is_ascii_alphabetic());\n assert!('C'.is_ascii_hexdigit());\n\n '0'.is_ascii_digit();\n 'a'.is_ascii_lowercase();\n 'A'.is_ascii_uppercase();\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nSuggests to use dedicated built-in methods,\n`is_ascii_(lowercase|uppercase|digit|hexdigit)` for checking on corresponding\nascii range\n\n### Why is this bad?\nUsing the built-in functions is more readable and makes it\nclear that it's not a specific subset of characters, but all\nASCII (lowercase|uppercase|digit|hexdigit) characters.\n### Example\n```rust\nfn main() {\n assert!(matches!('x', 'a'..='z'));\n assert!(matches!(b'X', b'A'..=b'Z'));\n assert!(matches!('2', '0'..='9'));\n assert!(matches!('x', 'A'..='Z' | 'a'..='z'));\n assert!(matches!('C', '0'..='9' | 'a'..='f' | 'A'..='F'));\n\n ('0'..='9').contains(&'0');\n ('a'..='z').contains(&'a');\n ('A'..='Z').contains(&'A');\n}\n```\nUse instead:\n```rust\nfn main() {\n assert!('x'.is_ascii_lowercase());\n assert!(b'X'.is_ascii_uppercase());\n assert!('2'.is_ascii_digit());\n assert!('x'.is_ascii_alphabetic());\n assert!('C'.is_ascii_hexdigit());\n\n '0'.is_ascii_digit();\n 'a'.is_ascii_lowercase();\n 'A'.is_ascii_uppercase();\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.67.0", "applicability": { "is_multi_part_suggestion": false, @@ -4196,11 +4196,11 @@ "id": "manual_let_else", "id_span": { "path": "src/manual_let_else.rs", - "line": 47 + "line": 48 }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\n\nWarn of cases where `let...else` could be used\n\n### Why is this bad?\n\n`let...else` provides a standard construct for this pattern\nthat people can easily recognize. It's also more compact.\n\n### Example\n\n```rust\nlet v = if let Some(v) = w { v } else { return };\n```\n\nCould be written:\n\n```rust\nlet Some(v) = w else { return };\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n* `matches-for-let-else`: `crate::manual_let_else::MatchLintBehaviour`(defaults to `WellKnownTypes`): Whether the matches should be considered by the lint, and whether there should\n be filtering for common types.\n", + "docs": "\n### What it does\n\nWarn of cases where `let...else` could be used\n\n### Why is this bad?\n\n`let...else` provides a standard construct for this pattern\nthat people can easily recognize. It's also more compact.\n\n### Example\n\n```rust\nlet v = if let Some(v) = w { v } else { return };\n```\n\nCould be written:\n\n```rust\nlet Some(v) = w else { return };\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`- `matches-for-let-else`: Whether the matches should be considered by the lint, and whether there should\n be filtering for common types. (default: `\"WellKnownTypes\"`)", "version": "1.67.0", "applicability": { "is_multi_part_suggestion": false, @@ -4275,7 +4275,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for manual implementations of the non-exhaustive pattern.\n\n### Why is this bad?\nUsing the #[non_exhaustive] attribute expresses better the intent\nand allows possible optimizations when applied to enums.\n\n### Example\n```rust\nstruct S {\n pub a: i32,\n pub b: i32,\n _c: (),\n}\n\nenum E {\n A,\n B,\n #[doc(hidden)]\n _C,\n}\n\nstruct T(pub i32, pub i32, ());\n```\nUse instead:\n```rust\n#[non_exhaustive]\nstruct S {\n pub a: i32,\n pub b: i32,\n}\n\n#[non_exhaustive]\nenum E {\n A,\n B,\n}\n\n#[non_exhaustive]\nstruct T(pub i32, pub i32);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for manual implementations of the non-exhaustive pattern.\n\n### Why is this bad?\nUsing the #[non_exhaustive] attribute expresses better the intent\nand allows possible optimizations when applied to enums.\n\n### Example\n```rust\nstruct S {\n pub a: i32,\n pub b: i32,\n _c: (),\n}\n\nenum E {\n A,\n B,\n #[doc(hidden)]\n _C,\n}\n\nstruct T(pub i32, pub i32, ());\n```\nUse instead:\n```rust\n#[non_exhaustive]\nstruct S {\n pub a: i32,\n pub b: i32,\n}\n\n#[non_exhaustive]\nenum E {\n A,\n B,\n}\n\n#[non_exhaustive]\nstruct T(pub i32, pub i32);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.45.0", "applicability": { "is_multi_part_suggestion": false, @@ -4305,7 +4305,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for expressions like `x >= 3 && x < 8` that could\nbe more readably expressed as `(3..8).contains(x)`.\n\n### Why is this bad?\n`contains` expresses the intent better and has less\nfailure modes (such as fencepost errors or using `||` instead of `&&`).\n\n### Example\n```rust\n// given\nlet x = 6;\n\nassert!(x >= 3 && x < 8);\n```\nUse instead:\n```rust\nassert!((3..8).contains(&x));\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for expressions like `x >= 3 && x < 8` that could\nbe more readably expressed as `(3..8).contains(x)`.\n\n### Why is this bad?\n`contains` expresses the intent better and has less\nfailure modes (such as fencepost errors or using `||` instead of `&&`).\n\n### Example\n```rust\n// given\nlet x = 6;\n\nassert!(x >= 3 && x < 8);\n```\nUse instead:\n```rust\nassert!((3..8).contains(&x));\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.49.0", "applicability": { "is_multi_part_suggestion": false, @@ -4335,7 +4335,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\nChecks for an expression like `((x % 4) + 4) % 4` which is a common manual reimplementation\nof `x.rem_euclid(4)`.\n\n### Why is this bad?\nIt's simpler and more readable.\n\n### Example\n```rust\nlet x: i32 = 24;\nlet rem = ((x % 4) + 4) % 4;\n```\nUse instead:\n```rust\nlet x: i32 = 24;\nlet rem = x.rem_euclid(4);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for an expression like `((x % 4) + 4) % 4` which is a common manual reimplementation\nof `x.rem_euclid(4)`.\n\n### Why is this bad?\nIt's simpler and more readable.\n\n### Example\n```rust\nlet x: i32 = 24;\nlet rem = ((x % 4) + 4) % 4;\n```\nUse instead:\n```rust\nlet x: i32 = 24;\nlet rem = x.rem_euclid(4);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.64.0", "applicability": { "is_multi_part_suggestion": false, @@ -4350,7 +4350,7 @@ }, "group": "perf", "level": "warn", - "docs": "\n### What it does\nChecks for code to be replaced by `.retain()`.\n### Why is this bad?\n`.retain()` is simpler and avoids needless allocation.\n### Example\n```rust\nlet mut vec = vec![0, 1, 2];\nvec = vec.iter().filter(|&x| x % 2 == 0).copied().collect();\nvec = vec.into_iter().filter(|x| x % 2 == 0).collect();\n```\nUse instead:\n```rust\nlet mut vec = vec![0, 1, 2];\nvec.retain(|x| x % 2 == 0);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for code to be replaced by `.retain()`.\n### Why is this bad?\n`.retain()` is simpler and avoids needless allocation.\n### Example\n```rust\nlet mut vec = vec![0, 1, 2];\nvec = vec.iter().filter(|&x| x % 2 == 0).copied().collect();\nvec = vec.into_iter().filter(|x| x % 2 == 0).collect();\n```\nUse instead:\n```rust\nlet mut vec = vec![0, 1, 2];\nvec.retain(|x| x % 2 == 0);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.64.0", "applicability": { "is_multi_part_suggestion": false, @@ -4395,7 +4395,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\nChecks for usage of `str::splitn(2, _)`\n\n### Why is this bad?\n`split_once` is both clearer in intent and slightly more efficient.\n\n### Example\n```rust\nlet s = \"key=value=add\";\nlet (key, value) = s.splitn(2, '=').next_tuple()?;\nlet value = s.splitn(2, '=').nth(1)?;\n\nlet mut parts = s.splitn(2, '=');\nlet key = parts.next()?;\nlet value = parts.next()?;\n```\n\nUse instead:\n```rust\nlet s = \"key=value=add\";\nlet (key, value) = s.split_once('=')?;\nlet value = s.split_once('=')?.1;\n\nlet (key, value) = s.split_once('=')?;\n```\n\n### Limitations\nThe multiple statement variant currently only detects `iter.next()?`/`iter.next().unwrap()`\nin two separate `let` statements that immediately follow the `splitn()`\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for usage of `str::splitn(2, _)`\n\n### Why is this bad?\n`split_once` is both clearer in intent and slightly more efficient.\n\n### Example\n```rust\nlet s = \"key=value=add\";\nlet (key, value) = s.splitn(2, '=').next_tuple()?;\nlet value = s.splitn(2, '=').nth(1)?;\n\nlet mut parts = s.splitn(2, '=');\nlet key = parts.next()?;\nlet value = parts.next()?;\n```\n\nUse instead:\n```rust\nlet s = \"key=value=add\";\nlet (key, value) = s.split_once('=')?;\nlet value = s.split_once('=')?.1;\n\nlet (key, value) = s.split_once('=')?;\n```\n\n### Limitations\nThe multiple statement variant currently only detects `iter.next()?`/`iter.next().unwrap()`\nin two separate `let` statements that immediately follow the `splitn()`\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.57.0", "applicability": { "is_multi_part_suggestion": false, @@ -4410,7 +4410,7 @@ }, "group": "perf", "level": "warn", - "docs": "\n### What it does\nChecks for manual implementations of `str::repeat`\n\n### Why is this bad?\nThese are both harder to read, as well as less performant.\n\n### Example\n```rust\nlet x: String = std::iter::repeat('x').take(10).collect();\n```\n\nUse instead:\n```rust\nlet x: String = \"x\".repeat(10);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for manual implementations of `str::repeat`\n\n### Why is this bad?\nThese are both harder to read, as well as less performant.\n\n### Example\n```rust\nlet x: String = std::iter::repeat('x').take(10).collect();\n```\n\nUse instead:\n```rust\nlet x: String = \"x\".repeat(10);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.54.0", "applicability": { "is_multi_part_suggestion": false, @@ -4440,7 +4440,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\nSuggests using `strip_{prefix,suffix}` over `str::{starts,ends}_with` and slicing using\nthe pattern's length.\n\n### Why is this bad?\nUsing `str:strip_{prefix,suffix}` is safer and may have better performance as there is no\nslicing which may panic and the compiler does not need to insert this panic code. It is\nalso sometimes more readable as it removes the need for duplicating or storing the pattern\nused by `str::{starts,ends}_with` and in the slicing.\n\n### Example\n```rust\nlet s = \"hello, world!\";\nif s.starts_with(\"hello, \") {\n assert_eq!(s[\"hello, \".len()..].to_uppercase(), \"WORLD!\");\n}\n```\nUse instead:\n```rust\nlet s = \"hello, world!\";\nif let Some(end) = s.strip_prefix(\"hello, \") {\n assert_eq!(end.to_uppercase(), \"WORLD!\");\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nSuggests using `strip_{prefix,suffix}` over `str::{starts,ends}_with` and slicing using\nthe pattern's length.\n\n### Why is this bad?\nUsing `str:strip_{prefix,suffix}` is safer and may have better performance as there is no\nslicing which may panic and the compiler does not need to insert this panic code. It is\nalso sometimes more readable as it removes the need for duplicating or storing the pattern\nused by `str::{starts,ends}_with` and in the slicing.\n\n### Example\n```rust\nlet s = \"hello, world!\";\nif s.starts_with(\"hello, \") {\n assert_eq!(s[\"hello, \".len()..].to_uppercase(), \"WORLD!\");\n}\n```\nUse instead:\n```rust\nlet s = \"hello, world!\";\nif let Some(end) = s.strip_prefix(\"hello, \") {\n assert_eq!(end.to_uppercase(), \"WORLD!\");\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.48.0", "applicability": { "is_multi_part_suggestion": false, @@ -4470,7 +4470,7 @@ }, "group": "perf", "level": "warn", - "docs": "\n### What it does\nChecks for usage of `Iterator::fold` with a type that implements `Try`.\n\n### Why is this bad?\nThe code should use `try_fold` instead, which short-circuits on failure, thus opening the\ndoor for additional optimizations not possible with `fold` as rustc can guarantee the\nfunction is never called on `None`, `Err`, etc., alleviating otherwise necessary checks. It's\nalso slightly more idiomatic.\n\n### Known issues\nThis lint doesn't take into account whether a function does something on the failure case,\ni.e., whether short-circuiting will affect behavior. Refactoring to `try_fold` is not\ndesirable in those cases.\n\n### Example\n```rust\nvec![1, 2, 3].iter().fold(Some(0i32), |sum, i| sum?.checked_add(*i));\n```\nUse instead:\n```rust\nvec![1, 2, 3].iter().try_fold(0i32, |sum, i| sum.checked_add(*i));\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for usage of `Iterator::fold` with a type that implements `Try`.\n\n### Why is this bad?\nThe code should use `try_fold` instead, which short-circuits on failure, thus opening the\ndoor for additional optimizations not possible with `fold` as rustc can guarantee the\nfunction is never called on `None`, `Err`, etc., alleviating otherwise necessary checks. It's\nalso slightly more idiomatic.\n\n### Known issues\nThis lint doesn't take into account whether a function does something on the failure case,\ni.e., whether short-circuiting will affect behavior. Refactoring to `try_fold` is not\ndesirable in those cases.\n\n### Example\n```rust\nvec![1, 2, 3].iter().fold(Some(0i32), |sum, i| sum?.checked_add(*i));\n```\nUse instead:\n```rust\nvec![1, 2, 3].iter().try_fold(0i32, |sum, i| sum.checked_add(*i));\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.72.0", "applicability": { "is_multi_part_suggestion": false, @@ -4515,7 +4515,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for too many variables whose name consists of a\nsingle character.\n\n### Why is this bad?\nIt's hard to memorize what a variable means without a\ndescriptive name.\n\n### Example\n```rust\nlet (a, b, c, d, e, f, g) = (...);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `single-char-binding-names-threshold`: `u64`(defaults to `4`): The maximum number of single char bindings a scope may have\n", + "docs": "\n### What it does\nChecks for too many variables whose name consists of a\nsingle character.\n\n### Why is this bad?\nIt's hard to memorize what a variable means without a\ndescriptive name.\n\n### Example\n```rust\nlet (a, b, c, d, e, f, g) = (...);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `single-char-binding-names-threshold`: The maximum number of single char bindings a scope may have (default: `4`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -4530,7 +4530,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for usage of `map(|x| x.clone())` or\ndereferencing closures for `Copy` types, on `Iterator` or `Option`,\nand suggests `cloned()` or `copied()` instead\n\n### Why is this bad?\nReadability, this can be written more concisely\n\n### Example\n```rust\nlet x = vec![42, 43];\nlet y = x.iter();\nlet z = y.map(|i| *i);\n```\n\nThe correct use would be:\n\n```rust\nlet x = vec![42, 43];\nlet y = x.iter();\nlet z = y.cloned();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for usage of `map(|x| x.clone())` or\ndereferencing closures for `Copy` types, on `Iterator` or `Option`,\nand suggests `cloned()` or `copied()` instead\n\n### Why is this bad?\nReadability, this can be written more concisely\n\n### Example\n```rust\nlet x = vec![42, 43];\nlet y = x.iter();\nlet z = y.map(|i| *i);\n```\n\nThe correct use would be:\n\n```rust\nlet x = vec![42, 43];\nlet y = x.iter();\nlet z = y.cloned();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -4620,7 +4620,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for usage of `option.map(_).unwrap_or(_)` or `option.map(_).unwrap_or_else(_)` or\n`result.map(_).unwrap_or_else(_)`.\n\n### Why is this bad?\nReadability, these can be written more concisely (resp.) as\n`option.map_or(_, _)`, `option.map_or_else(_, _)` and `result.map_or_else(_, _)`.\n\n### Known problems\nThe order of the arguments is not in execution order\n\n### Examples\n```rust\noption.map(|a| a + 1).unwrap_or(0);\noption.map(|a| a > 10).unwrap_or(false);\nresult.map(|a| a + 1).unwrap_or_else(some_function);\n```\n\nUse instead:\n```rust\noption.map_or(0, |a| a + 1);\noption.is_some_and(|a| a > 10);\nresult.map_or_else(some_function, |a| a + 1);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n\n### Past names\n\n* `option_map_unwrap_or`\n* `option_map_unwrap_or_else`\n* `result_map_unwrap_or_else`\n\n", + "docs": "\n### What it does\nChecks for usage of `option.map(_).unwrap_or(_)` or `option.map(_).unwrap_or_else(_)` or\n`result.map(_).unwrap_or_else(_)`.\n\n### Why is this bad?\nReadability, these can be written more concisely (resp.) as\n`option.map_or(_, _)`, `option.map_or_else(_, _)` and `result.map_or_else(_, _)`.\n\n### Known problems\nThe order of the arguments is not in execution order\n\n### Examples\n```rust\noption.map(|a| a + 1).unwrap_or(0);\noption.map(|a| a > 10).unwrap_or(false);\nresult.map(|a| a + 1).unwrap_or_else(some_function);\n```\n\nUse instead:\n```rust\noption.map_or(0, |a| a + 1);\noption.is_some_and(|a| a > 10);\nresult.map_or_else(some_function, |a| a + 1);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`\n### Past names\n\n* `option_map_unwrap_or`\n* `option_map_unwrap_or_else`\n* `result_map_unwrap_or_else`\n\n", "version": "1.45.0", "applicability": { "is_multi_part_suggestion": false, @@ -4670,7 +4670,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for `match` or `if let` expressions producing a\n`bool` that could be written using `matches!`\n\n### Why is this bad?\nReadability and needless complexity.\n\n### Known problems\nThis lint falsely triggers, if there are arms with\n`cfg` attributes that remove an arm evaluating to `false`.\n\n### Example\n```rust\nlet x = Some(5);\n\nlet a = match x {\n Some(0) => true,\n _ => false,\n};\n\nlet a = if let Some(0) = x {\n true\n} else {\n false\n};\n```\n\nUse instead:\n```rust\nlet x = Some(5);\nlet a = matches!(x, Some(0));\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for `match` or `if let` expressions producing a\n`bool` that could be written using `matches!`\n\n### Why is this bad?\nReadability and needless complexity.\n\n### Known problems\nThis lint falsely triggers, if there are arms with\n`cfg` attributes that remove an arm evaluating to `false`.\n\n### Example\n```rust\nlet x = Some(5);\n\nlet a = match x {\n Some(0) => true,\n _ => false,\n};\n\nlet a = if let Some(0) = x {\n true\n} else {\n false\n};\n```\n\nUse instead:\n```rust\nlet x = Some(5);\nlet a = matches!(x, Some(0));\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.47.0", "applicability": { "is_multi_part_suggestion": false, @@ -4883,7 +4883,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for `std::mem::replace` on a value of type\n`T` with `T::default()`.\n\n### Why is this bad?\n`std::mem` module already has the method `take` to\ntake the current value and replace it with the default value of that type.\n\n### Example\n```rust\nlet mut text = String::from(\"foo\");\nlet replaced = std::mem::replace(&mut text, String::default());\n```\nIs better expressed with:\n```rust\nlet mut text = String::from(\"foo\");\nlet taken = std::mem::take(&mut text);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for `std::mem::replace` on a value of type\n`T` with `T::default()`.\n\n### Why is this bad?\n`std::mem` module already has the method `take` to\ntake the current value and replace it with the default value of that type.\n\n### Example\n```rust\nlet mut text = String::from(\"foo\");\nlet replaced = std::mem::replace(&mut text, String::default());\n```\nIs better expressed with:\n```rust\nlet mut text = String::from(\"foo\");\nlet taken = std::mem::take(&mut text);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.42.0", "applicability": { "is_multi_part_suggestion": false, @@ -4913,7 +4913,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for idents which comprise of a single letter.\n\nNote: This lint can be very noisy when enabled; it may be desirable to only enable it\ntemporarily.\n\n### Why is this bad?\nIn many cases it's not, but at times it can severely hinder readability. Some codebases may\nwish to disallow this to improve readability.\n\n### Example\n```rust\nfor m in movies {\n let title = m.t;\n}\n```\nUse instead:\n```rust\nfor movie in movies {\n let title = movie.title;\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `allowed-idents-below-min-chars`: `rustc_data_structures::fx::FxHashSet`(defaults to `{\"j\", \"z\", \"i\", \"y\", \"n\", \"x\", \"w\"}`): Allowed names below the minimum allowed characters. The value `\"..\"` can be used as part of\n the list to indicate, that the configured values should be appended to the default\n configuration of Clippy. By default, any configuration will replace the default value.\n* `min-ident-chars-threshold`: `u64`(defaults to `1`): Minimum chars an ident can have, anything below or equal to this will be linted.\n", + "docs": "\n### What it does\nChecks for idents which comprise of a single letter.\n\nNote: This lint can be very noisy when enabled; it may be desirable to only enable it\ntemporarily.\n\n### Why is this bad?\nIn many cases it's not, but at times it can severely hinder readability. Some codebases may\nwish to disallow this to improve readability.\n\n### Example\n```rust\nfor m in movies {\n let title = m.t;\n}\n```\nUse instead:\n```rust\nfor movie in movies {\n let title = movie.title;\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `allowed-idents-below-min-chars`: Allowed names below the minimum allowed characters. The value `\"..\"` can be used as part of\n the list to indicate, that the configured values should be appended to the default\n configuration of Clippy. By default, any configuration will replace the default value. (default: `[\"j\", \"z\", \"i\", \"y\", \"n\", \"x\", \"w\"]`)- `min-ident-chars-threshold`: Minimum chars an ident can have, anything below or equal to this will be linted. (default: `1`)", "version": "1.72.0", "applicability": { "is_multi_part_suggestion": false, @@ -5048,7 +5048,7 @@ }, "group": "nursery", "level": "allow", - "docs": "\n### What it does\nSuggests the use of `const` in functions and methods where possible.\n\n### Why is this bad?\nNot having the function const prevents callers of the function from being const as well.\n\n### Known problems\nConst functions are currently still being worked on, with some features only being available\non nightly. This lint does not consider all edge cases currently and the suggestions may be\nincorrect if you are using this lint on stable.\n\nAlso, the lint only runs one pass over the code. Consider these two non-const functions:\n\n```rust\nfn a() -> i32 {\n 0\n}\nfn b() -> i32 {\n a()\n}\n```\n\nWhen running Clippy, the lint will only suggest to make `a` const, because `b` at this time\ncan't be const as it calls a non-const function. Making `a` const and running Clippy again,\nwill suggest to make `b` const, too.\n\nIf you are marking a public function with `const`, removing it again will break API compatibility.\n### Example\n```rust\nfn new() -> Self {\n Self { random_number: 42 }\n}\n```\n\nCould be a const fn:\n\n```rust\nconst fn new() -> Self {\n Self { random_number: 42 }\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nSuggests the use of `const` in functions and methods where possible.\n\n### Why is this bad?\nNot having the function const prevents callers of the function from being const as well.\n\n### Known problems\nConst functions are currently still being worked on, with some features only being available\non nightly. This lint does not consider all edge cases currently and the suggestions may be\nincorrect if you are using this lint on stable.\n\nAlso, the lint only runs one pass over the code. Consider these two non-const functions:\n\n```rust\nfn a() -> i32 {\n 0\n}\nfn b() -> i32 {\n a()\n}\n```\n\nWhen running Clippy, the lint will only suggest to make `a` const, because `b` at this time\ncan't be const as it calls a non-const function. Making `a` const and running Clippy again,\nwill suggest to make `b` const, too.\n\nIf you are marking a public function with `const`, removing it again will break API compatibility.\n### Example\n```rust\nfn new() -> Self {\n Self { random_number: 42 }\n}\n```\n\nCould be a const fn:\n\n```rust\nconst fn new() -> Self {\n Self { random_number: 42 }\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.34.0", "applicability": { "is_multi_part_suggestion": false, @@ -5063,7 +5063,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nWarns if there is missing doc for any private documentable item\n\n### Why is this bad?\nDoc is good. *rustc* has a `MISSING_DOCS`\nallowed-by-default lint for\npublic members, but has no way to enforce documentation of private items.\nThis lint fixes that.\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `missing-docs-in-crate-items`: `bool`(defaults to `false`): Whether to **only** check for missing documentation in items visible within the current\n crate. For example, `pub(crate)` items.\n", + "docs": "\n### What it does\nWarns if there is missing doc for any private documentable item\n\n### Why is this bad?\nDoc is good. *rustc* has a `MISSING_DOCS`\nallowed-by-default lint for\npublic members, but has no way to enforce documentation of private items.\nThis lint fixes that.\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `missing-docs-in-crate-items`: Whether to **only** check for missing documentation in items visible within the current\n crate. For example, `pub(crate)` items. (default: `false`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -5074,11 +5074,11 @@ "id": "missing_enforced_import_renames", "id_span": { "path": "src/missing_enforced_import_rename.rs", - "line": 43 + "line": 41 }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for imports that do not rename the item as specified\nin the `enforce-import-renames` config option.\n\nNote: Even though this lint is warn-by-default, it will only trigger if\nimport renames are defined in the clippy.toml file.\n\n### Why is this bad?\nConsistency is important, if a project has defined import\nrenames they should be followed. More practically, some item names are too\nvague outside of their defining scope this can enforce a more meaningful naming.\n\n### Example\nAn example clippy.toml configuration:\n```toml\n# clippy.toml\nenforced-import-renames = [ { path = \"serde_json::Value\", rename = \"JsonValue\" }]\n```\n\n```rust\nuse serde_json::Value;\n```\nUse instead:\n```rust\nuse serde_json::Value as JsonValue;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `enforced-import-renames`: `Vec`(defaults to `[]`): The list of imports to always rename, a fully qualified path followed by the rename.\n", + "docs": "\n### What it does\nChecks for imports that do not rename the item as specified\nin the `enforce-import-renames` config option.\n\nNote: Even though this lint is warn-by-default, it will only trigger if\nimport renames are defined in the clippy.toml file.\n\n### Why is this bad?\nConsistency is important, if a project has defined import\nrenames they should be followed. More practically, some item names are too\nvague outside of their defining scope this can enforce a more meaningful naming.\n\n### Example\nAn example clippy.toml configuration:\n```toml\n# clippy.toml\nenforced-import-renames = [ { path = \"serde_json::Value\", rename = \"JsonValue\" }]\n```\n\n```rust\nuse serde_json::Value;\n```\nUse instead:\n```rust\nuse serde_json::Value as JsonValue;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `enforced-import-renames`: The list of imports to always rename, a fully qualified path followed by the rename. (default: `[]`)", "version": "1.55.0", "applicability": { "is_multi_part_suggestion": false, @@ -5261,7 +5261,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for modules that have the same name as their\nparent module\n\n### Why is this bad?\nA typical beginner mistake is to have `mod foo;` and\nagain `mod foo { ..\n}` in `foo.rs`.\nThe expectation is that items inside the inner `mod foo { .. }` are then\navailable\nthrough `foo::x`, but they are only available through\n`foo::foo::x`.\nIf this is done on purpose, it would be better to choose a more\nrepresentative module name.\n\n### Example\n```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `allow-private-module-inception`: `bool`(defaults to `false`): Whether to allow module inception if it's not public.\n", + "docs": "\n### What it does\nChecks for modules that have the same name as their\nparent module\n\n### Why is this bad?\nA typical beginner mistake is to have `mod foo;` and\nagain `mod foo { ..\n}` in `foo.rs`.\nThe expectation is that items inside the inner `mod foo { .. }` are then\navailable\nthrough `foo::x`, but they are only available through\n`foo::foo::x`.\nIf this is done on purpose, it would be better to choose a more\nrepresentative module name.\n\n### Example\n```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `allow-private-module-inception`: Whether to allow module inception if it's not public. (default: `false`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -5474,7 +5474,7 @@ }, "group": "suspicious", "level": "warn", - "docs": "\n### What it does\nChecks for sets/maps with mutable key types.\n\n### Why is this bad?\nAll of `HashMap`, `HashSet`, `BTreeMap` and\n`BtreeSet` rely on either the hash or the order of keys be unchanging,\nso having types with interior mutability is a bad idea.\n\n### Known problems\n\n#### False Positives\nIt's correct to use a struct that contains interior mutability as a key, when its\nimplementation of `Hash` or `Ord` doesn't access any of the interior mutable types.\nHowever, this lint is unable to recognize this, so it will often cause false positives in\ntheses cases. The `bytes` crate is a great example of this.\n\n#### False Negatives\nFor custom `struct`s/`enum`s, this lint is unable to check for interior mutability behind\nindirection. For example, `struct BadKey<'a>(&'a Cell)` will be seen as immutable\nand cause a false negative if its implementation of `Hash`/`Ord` accesses the `Cell`.\n\nThis lint does check a few cases for indirection. Firstly, using some standard library\ntypes (`Option`, `Result`, `Box`, `Rc`, `Arc`, `Vec`, `VecDeque`, `BTreeMap` and\n`BTreeSet`) directly as keys (e.g. in `HashMap>, ()>`) **will** trigger the\nlint, because the impls of `Hash`/`Ord` for these types directly call `Hash`/`Ord` on their\ncontained type.\n\nSecondly, the implementations of `Hash` and `Ord` for raw pointers (`*const T` or `*mut T`)\napply only to the **address** of the contained value. Therefore, interior mutability\nbehind raw pointers (e.g. in `HashSet<*mut Cell>`) can't impact the value of `Hash`\nor `Ord`, and therefore will not trigger this link. For more info, see issue\n[#6745](https://github.com/rust-lang/rust-clippy/issues/6745).\n\n### Example\n```rust\nuse std::cmp::{PartialEq, Eq};\nuse std::collections::HashSet;\nuse std::hash::{Hash, Hasher};\nuse std::sync::atomic::AtomicUsize;\n\nstruct Bad(AtomicUsize);\nimpl PartialEq for Bad {\n fn eq(&self, rhs: &Self) -> bool {\n ..\n; unimplemented!();\n }\n}\n\nimpl Eq for Bad {}\n\nimpl Hash for Bad {\n fn hash(&self, h: &mut H) {\n ..\n; unimplemented!();\n }\n}\n\nfn main() {\n let _: HashSet = HashSet::new();\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `ignore-interior-mutability`: `Vec`(defaults to `[\"bytes::Bytes\"]`): A list of paths to types that should be treated like `Arc`, i.e. ignored but\n for the generic parameters for determining interior mutability\n", + "docs": "\n### What it does\nChecks for sets/maps with mutable key types.\n\n### Why is this bad?\nAll of `HashMap`, `HashSet`, `BTreeMap` and\n`BtreeSet` rely on either the hash or the order of keys be unchanging,\nso having types with interior mutability is a bad idea.\n\n### Known problems\n\n#### False Positives\nIt's correct to use a struct that contains interior mutability as a key, when its\nimplementation of `Hash` or `Ord` doesn't access any of the interior mutable types.\nHowever, this lint is unable to recognize this, so it will often cause false positives in\ntheses cases. The `bytes` crate is a great example of this.\n\n#### False Negatives\nFor custom `struct`s/`enum`s, this lint is unable to check for interior mutability behind\nindirection. For example, `struct BadKey<'a>(&'a Cell)` will be seen as immutable\nand cause a false negative if its implementation of `Hash`/`Ord` accesses the `Cell`.\n\nThis lint does check a few cases for indirection. Firstly, using some standard library\ntypes (`Option`, `Result`, `Box`, `Rc`, `Arc`, `Vec`, `VecDeque`, `BTreeMap` and\n`BTreeSet`) directly as keys (e.g. in `HashMap>, ()>`) **will** trigger the\nlint, because the impls of `Hash`/`Ord` for these types directly call `Hash`/`Ord` on their\ncontained type.\n\nSecondly, the implementations of `Hash` and `Ord` for raw pointers (`*const T` or `*mut T`)\napply only to the **address** of the contained value. Therefore, interior mutability\nbehind raw pointers (e.g. in `HashSet<*mut Cell>`) can't impact the value of `Hash`\nor `Ord`, and therefore will not trigger this link. For more info, see issue\n[#6745](https://github.com/rust-lang/rust-clippy/issues/6745).\n\n### Example\n```rust\nuse std::cmp::{PartialEq, Eq};\nuse std::collections::HashSet;\nuse std::hash::{Hash, Hasher};\nuse std::sync::atomic::AtomicUsize;\n\nstruct Bad(AtomicUsize);\nimpl PartialEq for Bad {\n fn eq(&self, rhs: &Self) -> bool {\n ..\n; unimplemented!();\n }\n}\n\nimpl Eq for Bad {}\n\nimpl Hash for Bad {\n fn hash(&self, h: &mut H) {\n ..\n; unimplemented!();\n }\n}\n\nfn main() {\n let _: HashSet = HashSet::new();\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `ignore-interior-mutability`: A list of paths to types that should be treated like `Arc`, i.e. ignored but\n for the generic parameters for determining interior mutability (default: `[\"bytes::Bytes\"]`)", "version": "1.42.0", "applicability": { "is_multi_part_suggestion": false, @@ -5594,7 +5594,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.\n\n### Why is this bad?\nSuggests that the receiver of the expression borrows\nthe expression.\n\n### Known problems\nThe lint cannot tell when the implementation of a trait\nfor `&T` and `T` do different things. Removing a borrow\nin such a case can change the semantics of the code.\n\n### Example\n```rust\nfn fun(_a: &i32) {}\n\nlet x: &i32 = &&&&&&5;\nfun(&x);\n```\n\nUse instead:\n```rust\nlet x: &i32 = &5;\nfun(x);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n\n### Past names\n\n* `ref_in_deref`\n\n", + "docs": "\n### What it does\nChecks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.\n\n### Why is this bad?\nSuggests that the receiver of the expression borrows\nthe expression.\n\n### Known problems\nThe lint cannot tell when the implementation of a trait\nfor `&T` and `T` do different things. Removing a borrow\nin such a case can change the semantics of the code.\n\n### Example\n```rust\nfn fun(_a: &i32) {}\n\nlet x: &i32 = &&&&&&5;\nfun(&x);\n```\n\nUse instead:\n```rust\nlet x: &i32 = &5;\nfun(x);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`\n### Past names\n\n* `ref_in_deref`\n\n", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -6221,7 +6221,7 @@ }, "group": "nursery", "level": "allow", - "docs": "\n### What it does\nThis lint warns about a `Send` implementation for a type that\ncontains fields that are not safe to be sent across threads.\nIt tries to detect fields that can cause a soundness issue\nwhen sent to another thread (e.g., `Rc`) while allowing `!Send` fields\nthat are expected to exist in a `Send` type, such as raw pointers.\n\n### Why is this bad?\nSending the struct to another thread effectively sends all of its fields,\nand the fields that do not implement `Send` can lead to soundness bugs\nsuch as data races when accessed in a thread\nthat is different from the thread that created it.\n\nSee:\n* [*The Rustonomicon* about *Send and Sync*](https://doc.rust-lang.org/nomicon/send-and-sync.html)\n* [The documentation of `Send`](https://doc.rust-lang.org/std/marker/trait.Send.html)\n\n### Known Problems\nThis lint relies on heuristics to distinguish types that are actually\nunsafe to be sent across threads and `!Send` types that are expected to\nexist in `Send` type. Its rule can filter out basic cases such as\n`Vec<*const T>`, but it's not perfect. Feel free to create an issue if\nyou have a suggestion on how this heuristic can be improved.\n\n### Example\n```rust\nstruct ExampleStruct {\n rc_is_not_send: Rc,\n unbounded_generic_field: T,\n}\n\n// This impl is unsound because it allows sending `!Send` types through `ExampleStruct`\nunsafe impl Send for ExampleStruct {}\n```\nUse thread-safe types like [`std::sync::Arc`](https://doc.rust-lang.org/std/sync/struct.Arc.html)\nor specify correct bounds on generic type parameters (`T: Send`).\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `enable-raw-pointer-heuristic-for-send`: `bool`(defaults to `true`): Whether to apply the raw pointer heuristic to determine if a type is `Send`.\n", + "docs": "\n### What it does\nThis lint warns about a `Send` implementation for a type that\ncontains fields that are not safe to be sent across threads.\nIt tries to detect fields that can cause a soundness issue\nwhen sent to another thread (e.g., `Rc`) while allowing `!Send` fields\nthat are expected to exist in a `Send` type, such as raw pointers.\n\n### Why is this bad?\nSending the struct to another thread effectively sends all of its fields,\nand the fields that do not implement `Send` can lead to soundness bugs\nsuch as data races when accessed in a thread\nthat is different from the thread that created it.\n\nSee:\n* [*The Rustonomicon* about *Send and Sync*](https://doc.rust-lang.org/nomicon/send-and-sync.html)\n* [The documentation of `Send`](https://doc.rust-lang.org/std/marker/trait.Send.html)\n\n### Known Problems\nThis lint relies on heuristics to distinguish types that are actually\nunsafe to be sent across threads and `!Send` types that are expected to\nexist in `Send` type. Its rule can filter out basic cases such as\n`Vec<*const T>`, but it's not perfect. Feel free to create an issue if\nyou have a suggestion on how this heuristic can be improved.\n\n### Example\n```rust\nstruct ExampleStruct {\n rc_is_not_send: Rc,\n unbounded_generic_field: T,\n}\n\n// This impl is unsound because it allows sending `!Send` types through `ExampleStruct`\nunsafe impl Send for ExampleStruct {}\n```\nUse thread-safe types like [`std::sync::Arc`](https://doc.rust-lang.org/std/sync/struct.Arc.html)\nor specify correct bounds on generic type parameters (`T: Send`).\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `enable-raw-pointer-heuristic-for-send`: Whether to apply the raw pointer heuristic to determine if a type is `Send`. (default: `true`)", "version": "1.57.0", "applicability": { "is_multi_part_suggestion": false, @@ -6262,11 +6262,11 @@ "id": "nonstandard_macro_braces", "id_span": { "path": "src/nonstandard_macro_braces.rs", - "line": 34 + "line": 31 }, "group": "nursery", "level": "allow", - "docs": "\n### What it does\nChecks that common macros are used with consistent bracing.\n\n### Why is this bad?\nThis is mostly a consistency lint although using () or []\ndoesn't give you a semicolon in item position, which can be unexpected.\n\n### Example\n```rust\nvec!{1, 2, 3};\n```\nUse instead:\n```rust\nvec![1, 2, 3];\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `standard-macro-braces`: `Vec`(defaults to `[]`): Enforce the named macros always use the braces specified.\n\n A `MacroMatcher` can be added like so `{ name = \"macro_name\", brace = \"(\" }`. If the macro\n could be used with a full path two `MacroMatcher`s have to be added one with the full path\n `crate_name::macro_name` and one with just the macro name.\n", + "docs": "\n### What it does\nChecks that common macros are used with consistent bracing.\n\n### Why is this bad?\nThis is mostly a consistency lint although using () or []\ndoesn't give you a semicolon in item position, which can be unexpected.\n\n### Example\n```rust\nvec!{1, 2, 3};\n```\nUse instead:\n```rust\nvec![1, 2, 3];\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `standard-macro-braces`: Enforce the named macros always use the braces specified.\n\n A `MacroMatcher` can be added like so `{ name = \"macro_name\", brace = \"(\" }`. If the macro\n could be used with a full path two `MacroMatcher`s have to be added one with the full path\n `crate_name::macro_name` and one with just the macro name. (default: `[]`)", "version": "1.55.0", "applicability": { "is_multi_part_suggestion": false, @@ -6371,7 +6371,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\nChecks for usage of `_.as_ref().map(Deref::deref)` or its aliases (such as String::as_str).\n\n### Why is this bad?\nReadability, this can be written more concisely as\n`_.as_deref()`.\n\n### Example\n```rust\nopt.as_ref().map(String::as_str)\n```\nCan be written as\n```rust\nopt.as_deref()\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for usage of `_.as_ref().map(Deref::deref)` or its aliases (such as String::as_str).\n\n### Why is this bad?\nReadability, this can be written more concisely as\n`_.as_deref()`.\n\n### Example\n```rust\nopt.as_ref().map(String::as_str)\n```\nCan be written as\n```rust\nopt.as_deref()\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.42.0", "applicability": { "is_multi_part_suggestion": false, @@ -6461,7 +6461,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for usage of `Option>` in function signatures and type\ndefinitions\n\n### Why is this bad?\n`Option<_>` represents an optional value. `Option>`\nrepresents an optional value which itself wraps an optional. This is logically the\nsame thing as an optional value but has an unneeded extra level of wrapping.\n\nIf you have a case where `Some(Some(_))`, `Some(None)` and `None` are distinct cases,\nconsider a custom `enum` instead, with clear names for each case.\n\n### Example\n```rust\nfn get_data() -> Option> {\n None\n}\n```\n\nBetter:\n\n```rust\npub enum Contents {\n Data(Vec), // Was Some(Some(Vec))\n NotYetFetched, // Was Some(None)\n None, // Was None\n}\n\nfn get_data() -> Contents {\n Contents::None\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n", + "docs": "\n### What it does\nChecks for usage of `Option>` in function signatures and type\ndefinitions\n\n### Why is this bad?\n`Option<_>` represents an optional value. `Option>`\nrepresents an optional value which itself wraps an optional. This is logically the\nsame thing as an optional value but has an unneeded extra level of wrapping.\n\nIf you have a case where `Some(Some(_))`, `Some(None)` and `None` are distinct cases,\nconsider a custom `enum` instead, with clear names for each case.\n\n### Example\n```rust\nfn get_data() -> Option> {\n None\n}\n```\n\nBetter:\n\n```rust\npub enum Contents {\n Data(Vec), // Was Some(Some(Vec))\n NotYetFetched, // Was Some(None)\n None, // Was None\n}\n\nfn get_data() -> Contents {\n Contents::None\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -6659,7 +6659,7 @@ }, "group": "suspicious", "level": "warn", - "docs": "\n### What it does\nLooks for calls to `Path::ends_with` calls where the argument looks like a file extension.\n\nBy default, Clippy has a short list of known filenames that start with a dot\nbut aren't necessarily file extensions (e.g. the `.git` folder), which are allowed by default.\nThe `allowed-dotfiles` configuration can be used to allow additional\nfile extensions that Clippy should not lint.\n\n### Why is this bad?\nThis doesn't actually compare file extensions. Rather, `ends_with` compares the given argument\nto the last **component** of the path and checks if it matches exactly.\n\n### Known issues\nFile extensions are often at most three characters long, so this only lints in those cases\nin an attempt to avoid false positives.\nAny extension names longer than that are assumed to likely be real path components and are\ntherefore ignored.\n\n### Example\n```rust\nfn is_markdown(path: &Path) -> bool {\n path.ends_with(\".md\")\n}\n```\nUse instead:\n```rust\nfn is_markdown(path: &Path) -> bool {\n path.extension().is_some_and(|ext| ext == \"md\")\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `allowed-dotfiles`: `rustc_data_structures::fx::FxHashSet`(defaults to `{}`): Additional dotfiles (files or directories starting with a dot) to allow\n", + "docs": "\n### What it does\nLooks for calls to `Path::ends_with` calls where the argument looks like a file extension.\n\nBy default, Clippy has a short list of known filenames that start with a dot\nbut aren't necessarily file extensions (e.g. the `.git` folder), which are allowed by default.\nThe `allowed-dotfiles` configuration can be used to allow additional\nfile extensions that Clippy should not lint.\n\n### Why is this bad?\nThis doesn't actually compare file extensions. Rather, `ends_with` compares the given argument\nto the last **component** of the path and checks if it matches exactly.\n\n### Known issues\nFile extensions are often at most three characters long, so this only lints in those cases\nin an attempt to avoid false positives.\nAny extension names longer than that are assumed to likely be real path components and are\ntherefore ignored.\n\n### Example\n```rust\nfn is_markdown(path: &Path) -> bool {\n path.ends_with(\".md\")\n}\n```\nUse instead:\n```rust\nfn is_markdown(path: &Path) -> bool {\n path.extension().is_some_and(|ext| ext == \"md\")\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `allowed-dotfiles`: Additional dotfiles (files or directories starting with a dot) to allow (default: `[]`)", "version": "1.74.0", "applicability": { "is_multi_part_suggestion": false, @@ -6764,7 +6764,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for printing on *stderr*. The purpose of this lint\nis to catch debugging remnants.\n\n### Why is this bad?\nPeople often print on *stderr* while debugging an\napplication and might forget to remove those prints afterward.\n\n### Known problems\nOnly catches `eprint!` and `eprintln!` calls.\n\n### Example\n```rust\neprintln!(\"Hello world!\");\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `allow-print-in-tests`: `bool`(defaults to `false`): Whether print macros (ex. `println!`) should be allowed in test functions or `#[cfg(test)]`\n", + "docs": "\n### What it does\nChecks for printing on *stderr*. The purpose of this lint\nis to catch debugging remnants.\n\n### Why is this bad?\nPeople often print on *stderr* while debugging an\napplication and might forget to remove those prints afterward.\n\n### Known problems\nOnly catches `eprint!` and `eprintln!` calls.\n\n### Example\n```rust\neprintln!(\"Hello world!\");\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `allow-print-in-tests`: Whether print macros (ex. `println!`) should be allowed in test functions or `#[cfg(test)]` (default: `false`)", "version": "1.50.0", "applicability": { "is_multi_part_suggestion": false, @@ -6779,7 +6779,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.\n\n### Why is this bad?\nPeople often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.\n\n### Known problems\nOnly catches `print!` and `println!` calls.\n\n### Example\n```rust\nprintln!(\"Hello world!\");\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `allow-print-in-tests`: `bool`(defaults to `false`): Whether print macros (ex. `println!`) should be allowed in test functions or `#[cfg(test)]`\n", + "docs": "\n### What it does\nChecks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.\n\n### Why is this bad?\nPeople often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.\n\n### Known problems\nOnly catches `print!` and `println!` calls.\n\n### Example\n```rust\nprintln!(\"Hello world!\");\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `allow-print-in-tests`: Whether print macros (ex. `println!`) should be allowed in test functions or `#[cfg(test)]` (default: `false`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -6839,7 +6839,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for `as` casts between raw pointers without changing its mutability,\nnamely `*const T` to `*const U` and `*mut T` to `*mut U`.\n\n### Why is this bad?\nThough `as` casts between raw pointers are not terrible, `pointer::cast` is safer because\nit cannot accidentally change the pointer's mutability nor cast the pointer to other types like `usize`.\n\n### Example\n```rust\nlet ptr: *const u32 = &42_u32;\nlet mut_ptr: *mut u32 = &mut 42_u32;\nlet _ = ptr as *const i32;\nlet _ = mut_ptr as *mut i32;\n```\nUse instead:\n```rust\nlet ptr: *const u32 = &42_u32;\nlet mut_ptr: *mut u32 = &mut 42_u32;\nlet _ = ptr.cast::();\nlet _ = mut_ptr.cast::();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for `as` casts between raw pointers without changing its mutability,\nnamely `*const T` to `*const U` and `*mut T` to `*mut U`.\n\n### Why is this bad?\nThough `as` casts between raw pointers are not terrible, `pointer::cast` is safer because\nit cannot accidentally change the pointer's mutability nor cast the pointer to other types like `usize`.\n\n### Example\n```rust\nlet ptr: *const u32 = &42_u32;\nlet mut_ptr: *mut u32 = &mut 42_u32;\nlet _ = ptr as *const i32;\nlet _ = mut_ptr as *mut i32;\n```\nUse instead:\n```rust\nlet ptr: *const u32 = &42_u32;\nlet mut_ptr: *mut u32 = &mut 42_u32;\nlet _ = ptr.cast::();\nlet _ = mut_ptr.cast::();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.51.0", "applicability": { "is_multi_part_suggestion": false, @@ -6955,7 +6955,7 @@ "id": "question_mark", "id_span": { "path": "src/question_mark.rs", - "line": 45 + "line": 46 }, "group": "style", "level": "warn", @@ -7049,7 +7049,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for `Rc` and `Arc` when `T` is a mutable buffer type such as `String` or `Vec`.\n\n### Why is this bad?\nExpressions such as `Rc` usually have no advantage over `Rc`, since\nit is larger and involves an extra level of indirection, and doesn't implement `Borrow`.\n\nWhile mutating a buffer type would still be possible with `Rc::get_mut()`, it only\nworks if there are no additional references yet, which usually defeats the purpose of\nenclosing it in a shared ownership type. Instead, additionally wrapping the inner\ntype with an interior mutable container (such as `RefCell` or `Mutex`) would normally\nbe used.\n\n### Known problems\nThis pattern can be desirable to avoid the overhead of a `RefCell` or `Mutex` for\ncases where mutation only happens before there are any additional references.\n\n### Example\n```rust\nfn foo(interned: Rc) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(interned: Rc) { ... }\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n", + "docs": "\n### What it does\nChecks for `Rc` and `Arc` when `T` is a mutable buffer type such as `String` or `Vec`.\n\n### Why is this bad?\nExpressions such as `Rc` usually have no advantage over `Rc`, since\nit is larger and involves an extra level of indirection, and doesn't implement `Borrow`.\n\nWhile mutating a buffer type would still be possible with `Rc::get_mut()`, it only\nworks if there are no additional references yet, which usually defeats the purpose of\nenclosing it in a shared ownership type. Instead, additionally wrapping the inner\ntype with an interior mutable container (such as `RefCell` or `Mutex`) would normally\nbe used.\n\n### Known problems\nThis pattern can be desirable to avoid the overhead of a `RefCell` or `Mutex` for\ncases where mutation only happens before there are any additional references.\n\n### Example\n```rust\nfn foo(interned: Rc) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(interned: Rc) { ... }\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)", "version": "1.48.0", "applicability": { "is_multi_part_suggestion": false, @@ -7079,7 +7079,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for `Rc>`.\n\n### Why is this bad?\n`Rc` is used in single thread and `Mutex` is used in multi thread.\nConsider using `Rc>` in single thread or `Arc>` in multi thread.\n\n### Known problems\nSometimes combining generic types can lead to the requirement that a\ntype use Rc in conjunction with Mutex. We must consider those cases false positives, but\nalas they are quite hard to rule out. Luckily they are also rare.\n\n### Example\n```rust\nuse std::rc::Rc;\nuse std::sync::Mutex;\nfn foo(interned: Rc>) { ... }\n```\n\nBetter:\n\n```rust\nuse std::rc::Rc;\nuse std::cell::RefCell\nfn foo(interned: Rc>) { ... }\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n", + "docs": "\n### What it does\nChecks for `Rc>`.\n\n### Why is this bad?\n`Rc` is used in single thread and `Mutex` is used in multi thread.\nConsider using `Rc>` in single thread or `Arc>` in multi thread.\n\n### Known problems\nSometimes combining generic types can lead to the requirement that a\ntype use Rc in conjunction with Mutex. We must consider those cases false positives, but\nalas they are quite hard to rule out. Luckily they are also rare.\n\n### Example\n```rust\nuse std::rc::Rc;\nuse std::sync::Mutex;\nfn foo(interned: Rc>) { ... }\n```\n\nBetter:\n\n```rust\nuse std::rc::Rc;\nuse std::cell::RefCell\nfn foo(interned: Rc>) { ... }\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)", "version": "1.55.0", "applicability": { "is_multi_part_suggestion": false, @@ -7157,7 +7157,7 @@ }, "group": "perf", "level": "warn", - "docs": "\n### What it does\nChecks for usage of redundant allocations anywhere in the code.\n\n### Why is this bad?\nExpressions such as `Rc<&T>`, `Rc>`, `Rc>`, `Rc>`, `Arc<&T>`, `Arc>`,\n`Arc>`, `Arc>`, `Box<&T>`, `Box>`, `Box>`, `Box>`, add an unnecessary level of indirection.\n\n### Example\n```rust\nfn foo(bar: Rc<&usize>) {}\n```\n\nBetter:\n\n```rust\nfn foo(bar: &usize) {}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n", + "docs": "\n### What it does\nChecks for usage of redundant allocations anywhere in the code.\n\n### Why is this bad?\nExpressions such as `Rc<&T>`, `Rc>`, `Rc>`, `Rc>`, `Arc<&T>`, `Arc>`,\n`Arc>`, `Arc>`, `Box<&T>`, `Box>`, `Box>`, `Box>`, add an unnecessary level of indirection.\n\n### Example\n```rust\nfn foo(bar: Rc<&usize>) {}\n```\n\nBetter:\n\n```rust\nfn foo(bar: &usize) {}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)", "version": "1.44.0", "applicability": { "is_multi_part_suggestion": false, @@ -7322,7 +7322,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for fields in struct literals where shorthands\ncould be used.\n\n### Why is this bad?\nIf the field and variable names are the same,\nthe field name is redundant.\n\n### Example\n```rust\nlet bar: u8 = 123;\n\nstruct Foo {\n bar: u8,\n}\n\nlet foo = Foo { bar: bar };\n```\nthe last line can be simplified to\n```rust\nlet foo = Foo { bar };\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for fields in struct literals where shorthands\ncould be used.\n\n### Why is this bad?\nIf the field and variable names are the same,\nthe field name is redundant.\n\n### Example\n```rust\nlet bar: u8 = 123;\n\nstruct Foo {\n bar: u8,\n}\n\nlet foo = Foo { bar: bar };\n```\nthe last line can be simplified to\n```rust\nlet foo = Foo { bar };\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -7427,7 +7427,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for constants and statics with an explicit `'static` lifetime.\n\n### Why is this bad?\nAdding `'static` to every reference can create very\ncomplicated types.\n\n### Example\n```rust\nconst FOO: &'static [(&'static str, &'static str, fn(&Bar) -> bool)] =\n&[...]\nstatic FOO: &'static [(&'static str, &'static str, fn(&Bar) -> bool)] =\n&[...]\n```\nThis code can be rewritten as\n```rust\n const FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n static FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n\n### Past names\n\n* `const_static_lifetime`\n\n", + "docs": "\n### What it does\nChecks for constants and statics with an explicit `'static` lifetime.\n\n### Why is this bad?\nAdding `'static` to every reference can create very\ncomplicated types.\n\n### Example\n```rust\nconst FOO: &'static [(&'static str, &'static str, fn(&Bar) -> bool)] =\n&[...]\nstatic FOO: &'static [(&'static str, &'static str, fn(&Bar) -> bool)] =\n&[...]\n```\nThis code can be rewritten as\n```rust\n const FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n static FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`\n### Past names\n\n* `const_static_lifetime`\n\n", "version": "1.37.0", "applicability": { "is_multi_part_suggestion": false, @@ -7580,7 +7580,7 @@ }, "group": "perf", "level": "warn", - "docs": "\n### What it does\nChecks for functions that return `Result` with an unusually large\n`Err`-variant.\n\n### Why is this bad?\nA `Result` is at least as large as the `Err`-variant. While we\nexpect that variant to be seldomly used, the compiler needs to reserve\nand move that much memory every single time.\nFurthermore, errors are often simply passed up the call-stack, making\nuse of the `?`-operator and its type-conversion mechanics. If the\n`Err`-variant further up the call-stack stores the `Err`-variant in\nquestion (as library code often does), it itself needs to be at least\nas large, propagating the problem.\n\n### Known problems\nThe size determined by Clippy is platform-dependent.\n\n### Examples\n```rust\npub enum ParseError {\n UnparsedBytes([u8; 512]),\n UnexpectedEof,\n}\n\n// The `Result` has at least 512 bytes, even in the `Ok`-case\npub fn parse() -> Result<(), ParseError> {\n Ok(())\n}\n```\nshould be\n```rust\npub enum ParseError {\n UnparsedBytes(Box<[u8; 512]>),\n UnexpectedEof,\n}\n\n// The `Result` is slightly larger than a pointer\npub fn parse() -> Result<(), ParseError> {\n Ok(())\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `large-error-threshold`: `u64`(defaults to `128`): The maximum size of the `Err`-variant in a `Result` returned from a function\n", + "docs": "\n### What it does\nChecks for functions that return `Result` with an unusually large\n`Err`-variant.\n\n### Why is this bad?\nA `Result` is at least as large as the `Err`-variant. While we\nexpect that variant to be seldomly used, the compiler needs to reserve\nand move that much memory every single time.\nFurthermore, errors are often simply passed up the call-stack, making\nuse of the `?`-operator and its type-conversion mechanics. If the\n`Err`-variant further up the call-stack stores the `Err`-variant in\nquestion (as library code often does), it itself needs to be at least\nas large, propagating the problem.\n\n### Known problems\nThe size determined by Clippy is platform-dependent.\n\n### Examples\n```rust\npub enum ParseError {\n UnparsedBytes([u8; 512]),\n UnexpectedEof,\n}\n\n// The `Result` has at least 512 bytes, even in the `Ok`-case\npub fn parse() -> Result<(), ParseError> {\n Ok(())\n}\n```\nshould be\n```rust\npub enum ParseError {\n UnparsedBytes(Box<[u8; 512]>),\n UnexpectedEof,\n}\n\n// The `Result` is slightly larger than a pointer\npub fn parse() -> Result<(), ParseError> {\n Ok(())\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `large-error-threshold`: The maximum size of the `Err`-variant in a `Result` returned from a function (default: `128`)", "version": "1.65.0", "applicability": { "is_multi_part_suggestion": false, @@ -7730,7 +7730,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\n\nChecks an argument of `seek` method of `Seek` trait\nand if it start seek from `SeekFrom::Current(0)`, suggests `stream_position` instead.\n\n### Why is this bad?\n\nReadability. Use dedicated method.\n\n### Example\n\n```rust\nuse std::fs::File;\nuse std::io::{self, Write, Seek, SeekFrom};\n\nfn main() -> io::Result<()> {\n let mut f = File::create(\"foo.txt\")?;\n f.write_all(b\"Hello\")?;\n eprintln!(\"Written {} bytes\", f.seek(SeekFrom::Current(0))?);\n\n Ok(())\n}\n```\nUse instead:\n```rust\nuse std::fs::File;\nuse std::io::{self, Write, Seek, SeekFrom};\n\nfn main() -> io::Result<()> {\n let mut f = File::create(\"foo.txt\")?;\n f.write_all(b\"Hello\")?;\n eprintln!(\"Written {} bytes\", f.stream_position()?);\n\n Ok(())\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\n\nChecks an argument of `seek` method of `Seek` trait\nand if it start seek from `SeekFrom::Current(0)`, suggests `stream_position` instead.\n\n### Why is this bad?\n\nReadability. Use dedicated method.\n\n### Example\n\n```rust\nuse std::fs::File;\nuse std::io::{self, Write, Seek, SeekFrom};\n\nfn main() -> io::Result<()> {\n let mut f = File::create(\"foo.txt\")?;\n f.write_all(b\"Hello\")?;\n eprintln!(\"Written {} bytes\", f.seek(SeekFrom::Current(0))?);\n\n Ok(())\n}\n```\nUse instead:\n```rust\nuse std::fs::File;\nuse std::io::{self, Write, Seek, SeekFrom};\n\nfn main() -> io::Result<()> {\n let mut f = File::create(\"foo.txt\")?;\n f.write_all(b\"Hello\")?;\n eprintln!(\"Written {} bytes\", f.stream_position()?);\n\n Ok(())\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.67.0", "applicability": { "is_multi_part_suggestion": false, @@ -7820,7 +7820,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\n\nSuggests moving the semicolon after a block to the inside of the block, after its last\nexpression.\n\n### Why is this bad?\n\nFor consistency it's best to have the semicolon inside/outside the block. Either way is fine\nand this lint suggests inside the block.\nTake a look at `semicolon_outside_block` for the other alternative.\n\n### Example\n\n```rust\nunsafe { f(x) };\n```\nUse instead:\n```rust\nunsafe { f(x); }\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `semicolon-inside-block-ignore-singleline`: `bool`(defaults to `false`): Whether to lint only if it's multiline.\n", + "docs": "\n### What it does\n\nSuggests moving the semicolon after a block to the inside of the block, after its last\nexpression.\n\n### Why is this bad?\n\nFor consistency it's best to have the semicolon inside/outside the block. Either way is fine\nand this lint suggests inside the block.\nTake a look at `semicolon_outside_block` for the other alternative.\n\n### Example\n\n```rust\nunsafe { f(x) };\n```\nUse instead:\n```rust\nunsafe { f(x); }\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `semicolon-inside-block-ignore-singleline`: Whether to lint only if it's multiline. (default: `false`)", "version": "1.68.0", "applicability": { "is_multi_part_suggestion": false, @@ -7835,7 +7835,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\n\nSuggests moving the semicolon from a block's final expression outside of the block.\n\n### Why is this bad?\n\nFor consistency it's best to have the semicolon inside/outside the block. Either way is fine\nand this lint suggests outside the block.\nTake a look at `semicolon_inside_block` for the other alternative.\n\n### Example\n\n```rust\nunsafe { f(x); }\n```\nUse instead:\n```rust\nunsafe { f(x) };\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `semicolon-outside-block-ignore-multiline`: `bool`(defaults to `false`): Whether to lint only if it's singleline.\n", + "docs": "\n### What it does\n\nSuggests moving the semicolon from a block's final expression outside of the block.\n\n### Why is this bad?\n\nFor consistency it's best to have the semicolon inside/outside the block. Either way is fine\nand this lint suggests outside the block.\nTake a look at `semicolon_inside_block` for the other alternative.\n\n### Example\n\n```rust\nunsafe { f(x); }\n```\nUse instead:\n```rust\nunsafe { f(x) };\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `semicolon-outside-block-ignore-multiline`: Whether to lint only if it's singleline. (default: `false`)", "version": "1.68.0", "applicability": { "is_multi_part_suggestion": false, @@ -8030,7 +8030,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for functions that are only used once. Does not lint tests.\n\n### Why is this bad?\nIt's usually not, splitting a function into multiple parts often improves readability and in\nthe case of generics, can prevent the compiler from duplicating the function dozens of\ntime; instead, only duplicating a thunk. But this can prevent segmentation across a\ncodebase, where many small functions are used only once.\n\nNote: If this lint is used, prepare to allow this a lot.\n\n### Example\n```rust\npub fn a(t: &T)\nwhere\n T: AsRef,\n{\n a_inner(t.as_ref())\n}\n\nfn a_inner(t: &str) {\n /* snip */\n}\n\n```\nUse instead:\n```rust\npub fn a(t: &T)\nwhere\n T: AsRef,\n{\n let t = t.as_ref();\n /* snip */\n}\n\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n", + "docs": "\n### What it does\nChecks for functions that are only used once. Does not lint tests.\n\n### Why is this bad?\nIt's usually not, splitting a function into multiple parts often improves readability and in\nthe case of generics, can prevent the compiler from duplicating the function dozens of\ntime; instead, only duplicating a thunk. But this can prevent segmentation across a\ncodebase, where many small functions are used only once.\n\nNote: If this lint is used, prepare to allow this a lot.\n\n### Example\n```rust\npub fn a(t: &T)\nwhere\n T: AsRef,\n{\n a_inner(t.as_ref())\n}\n\nfn a_inner(t: &str) {\n /* snip */\n}\n\n```\nUse instead:\n```rust\npub fn a(t: &T)\nwhere\n T: AsRef,\n{\n let t = t.as_ref();\n /* snip */\n}\n\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)", "version": "1.72.0", "applicability": { "is_multi_part_suggestion": false, @@ -8423,7 +8423,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for excessive\nuse of bools in structs.\n\n### Why is this bad?\nExcessive bools in a struct\nis often a sign that it's used as a state machine,\nwhich is much better implemented as an enum.\nIf it's not the case, excessive bools usually benefit\nfrom refactoring into two-variant enums for better\nreadability and API.\n\n### Example\n```rust\nstruct S {\n is_pending: bool,\n is_processing: bool,\n is_finished: bool,\n}\n```\n\nUse instead:\n```rust\nenum S {\n Pending,\n Processing,\n Finished,\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `max-struct-bools`: `u64`(defaults to `3`): The maximum number of bool fields a struct can have\n", + "docs": "\n### What it does\nChecks for excessive\nuse of bools in structs.\n\n### Why is this bad?\nExcessive bools in a struct\nis often a sign that it's used as a state machine,\nwhich is much better implemented as an enum.\nIf it's not the case, excessive bools usually benefit\nfrom refactoring into two-variant enums for better\nreadability and API.\n\n### Example\n```rust\nstruct S {\n is_pending: bool,\n is_processing: bool,\n is_finished: bool,\n}\n```\n\nUse instead:\n```rust\nenum S {\n Pending,\n Processing,\n Finished,\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `max-struct-bools`: The maximum number of bool fields a struct can have (default: `3`)", "version": "1.43.0", "applicability": { "is_multi_part_suggestion": false, @@ -8753,7 +8753,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\nChecks for functions with too many parameters.\n\n### Why is this bad?\nFunctions with lots of parameters are considered bad\nstyle and reduce readability (“what does the 5th parameter mean?”). Consider\ngrouping some parameters into a new type.\n\n### Example\n```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n // ..\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `too-many-arguments-threshold`: `u64`(defaults to `7`): The maximum number of argument a function or method can have\n", + "docs": "\n### What it does\nChecks for functions with too many parameters.\n\n### Why is this bad?\nFunctions with lots of parameters are considered bad\nstyle and reduce readability (“what does the 5th parameter mean?”). Consider\ngrouping some parameters into a new type.\n\n### Example\n```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n // ..\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `too-many-arguments-threshold`: The maximum number of argument a function or method can have (default: `7`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -8768,7 +8768,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for functions with a large amount of lines.\n\n### Why is this bad?\nFunctions with a lot of lines are harder to understand\ndue to having to look at a larger amount of code to understand what the\nfunction is doing. Consider splitting the body of the function into\nmultiple functions.\n\n### Example\n```rust\nfn im_too_long() {\n println!(\"\");\n // ... 100 more LoC\n println!(\"\");\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `too-many-lines-threshold`: `u64`(defaults to `100`): The maximum number of lines a function or method can have\n", + "docs": "\n### What it does\nChecks for functions with a large amount of lines.\n\n### Why is this bad?\nFunctions with a lot of lines are harder to understand\ndue to having to look at a larger amount of code to understand what the\nfunction is doing. Consider splitting the body of the function into\nmultiple functions.\n\n### Example\n```rust\nfn im_too_long() {\n println!(\"\");\n // ... 100 more LoC\n println!(\"\");\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `too-many-lines-threshold`: The maximum number of lines a function or method can have (default: `100`)", "version": "1.34.0", "applicability": { "is_multi_part_suggestion": false, @@ -8963,7 +8963,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\nChecks for transmutes from a pointer to a reference.\n\n### Why is this bad?\nThis can always be rewritten with `&` and `*`.\n\n### Known problems\n- `mem::transmute` in statics and constants is stable from Rust 1.46.0,\nwhile dereferencing raw pointer is not stable yet.\nIf you need to do this in those places,\nyou would have to use `transmute` instead.\n\n### Example\n```rust\nunsafe {\n let _: &T = std::mem::transmute(p); // where p: *const T\n}\n\n// can be written:\nlet _: &T = &*p;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for transmutes from a pointer to a reference.\n\n### Why is this bad?\nThis can always be rewritten with `&` and `*`.\n\n### Known problems\n- `mem::transmute` in statics and constants is stable from Rust 1.46.0,\nwhile dereferencing raw pointer is not stable yet.\nIf you need to do this in those places,\nyou would have to use `transmute` instead.\n\n### Example\n```rust\nunsafe {\n let _: &T = std::mem::transmute(p); // where p: *const T\n}\n\n// can be written:\nlet _: &T = &*p;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -9053,7 +9053,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.\n\n### Why is this bad?\nIn many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.\n\n### Known problems\nThis lint is target register size dependent, it is\nlimited to 32-bit to try and reduce portability problems between 32 and\n64-bit, but if you are compiling for 8 or 16-bit targets then the limit\nwill be different.\n\nThe configuration option `trivial_copy_size_limit` can be set to override\nthis limit for a project.\n\nThis lint attempts to allow passing arguments by reference if a reference\nto that argument is returned. This is implemented by comparing the lifetime\nof the argument and return value for equality. However, this can cause\nfalse positives in cases involving multiple lifetimes that are bounded by\neach other.\n\nAlso, it does not take account of other similar cases where getting memory addresses\nmatters; namely, returning the pointer to the argument in question,\nand passing the argument, as both references and pointers,\nto a function that needs the memory address. For further details, refer to\n[this issue](https://github.com/rust-lang/rust-clippy/issues/5953)\nthat explains a real case in which this false positive\nled to an **undefined behavior** introduced with unsafe code.\n\n### Example\n\n```rust\nfn foo(v: &u32) {}\n```\n\nUse instead:\n```rust\nfn foo(v: u32) {}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n* `trivial-copy-size-limit`: `Option`(defaults to `None`): The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference.\n", + "docs": "\n### What it does\nChecks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.\n\n### Why is this bad?\nIn many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.\n\n### Known problems\nThis lint is target register size dependent, it is\nlimited to 32-bit to try and reduce portability problems between 32 and\n64-bit, but if you are compiling for 8 or 16-bit targets then the limit\nwill be different.\n\nThe configuration option `trivial_copy_size_limit` can be set to override\nthis limit for a project.\n\nThis lint attempts to allow passing arguments by reference if a reference\nto that argument is returned. This is implemented by comparing the lifetime\nof the argument and return value for equality. However, this can cause\nfalse positives in cases involving multiple lifetimes that are bounded by\neach other.\n\nAlso, it does not take account of other similar cases where getting memory addresses\nmatters; namely, returning the pointer to the argument in question,\nand passing the argument, as both references and pointers,\nto a function that needs the memory address. For further details, refer to\n[this issue](https://github.com/rust-lang/rust-clippy/issues/5953)\nthat explains a real case in which this false positive\nled to an **undefined behavior** introduced with unsafe code.\n\n### Example\n\n```rust\nfn foo(v: &u32) {}\n```\n\nUse instead:\n```rust\nfn foo(v: u32) {}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)- `trivial-copy-size-limit`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by\n reference. By default there is no limit", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -9083,7 +9083,7 @@ }, "group": "nursery", "level": "allow", - "docs": "\n### What it does\nChecks for tuple<=>array conversions that are not done with `.into()`.\n\n### Why is this bad?\nIt may be unnecessary complexity. `.into()` works for converting tuples<=> arrays of up to\n12 elements and conveys the intent more clearly, while also leaving less room for hard to\nspot bugs!\n\n### Known issues\nThe suggested code may hide potential asymmetry in some cases. See\n[#11085](https://github.com/rust-lang/rust-clippy/issues/11085) for more info.\n\n### Example\n```rust\nlet t1 = &[(1, 2), (3, 4)];\nlet v1: Vec<[u32; 2]> = t1.iter().map(|&(a, b)| [a, b]).collect();\n```\nUse instead:\n```rust\nlet t1 = &[(1, 2), (3, 4)];\nlet v1: Vec<[u32; 2]> = t1.iter().map(|&t| t.into()).collect();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for tuple<=>array conversions that are not done with `.into()`.\n\n### Why is this bad?\nIt may be unnecessary complexity. `.into()` works for converting tuples<=> arrays of up to\n12 elements and conveys the intent more clearly, while also leaving less room for hard to\nspot bugs!\n\n### Known issues\nThe suggested code may hide potential asymmetry in some cases. See\n[#11085](https://github.com/rust-lang/rust-clippy/issues/11085) for more info.\n\n### Example\n```rust\nlet t1 = &[(1, 2), (3, 4)];\nlet v1: Vec<[u32; 2]> = t1.iter().map(|&(a, b)| [a, b]).collect();\n```\nUse instead:\n```rust\nlet t1 = &[(1, 2), (3, 4)];\nlet v1: Vec<[u32; 2]> = t1.iter().map(|&t| t.into()).collect();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.72.0", "applicability": { "is_multi_part_suggestion": false, @@ -9098,7 +9098,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\nChecks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.\n\n### Why is this bad?\nToo complex types make the code less readable. Consider\nusing a `type` definition to simplify them.\n\n### Example\n```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `type-complexity-threshold`: `u64`(defaults to `250`): The maximum complexity a type can have\n", + "docs": "\n### What it does\nChecks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.\n\n### Why is this bad?\nToo complex types make the code less readable. Consider\nusing a `type` definition to simplify them.\n\n### Example\n```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `type-complexity-threshold`: The maximum complexity a type can have (default: `250`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -9128,7 +9128,7 @@ }, "group": "nursery", "level": "allow", - "docs": "\n### What it does\nThis lint warns about unnecessary type repetitions in trait bounds\n\n### Why is this bad?\nRepeating the type for every bound makes the code\nless readable than combining the bounds\n\n### Example\n```rust\npub fn foo(t: T) where T: Copy, T: Clone {}\n```\n\nUse instead:\n```rust\npub fn foo(t: T) where T: Copy + Clone {}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n* `max-trait-bounds`: `u64`(defaults to `3`): The maximum number of bounds a trait can have to be linted\n", + "docs": "\n### What it does\nThis lint warns about unnecessary type repetitions in trait bounds\n\n### Why is this bad?\nRepeating the type for every bound makes the code\nless readable than combining the bounds\n\n### Example\n```rust\npub fn foo(t: T) where T: Copy, T: Clone {}\n```\n\nUse instead:\n```rust\npub fn foo(t: T) where T: Copy + Clone {}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`- `max-trait-bounds`: The maximum number of bounds a trait can have to be linted (default: `3`)", "version": "1.38.0", "applicability": { "is_multi_part_suggestion": false, @@ -9143,7 +9143,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nLints subtraction between an [`Instant`] and a [`Duration`].\n\n### Why is this bad?\nUnchecked subtraction could cause underflow on certain platforms, leading to\nunintentional panics.\n\n### Example\n```rust\nlet time_passed = Instant::now() - Duration::from_secs(5);\n```\n\nUse instead:\n```rust\nlet time_passed = Instant::now().checked_sub(Duration::from_secs(5));\n```\n\n[`Duration`]: std::time::Duration\n[`Instant::now()`]: std::time::Instant::now;\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nLints subtraction between an [`Instant`] and a [`Duration`].\n\n### Why is this bad?\nUnchecked subtraction could cause underflow on certain platforms, leading to\nunintentional panics.\n\n### Example\n```rust\nlet time_passed = Instant::now() - Duration::from_secs(5);\n```\n\nUse instead:\n```rust\nlet time_passed = Instant::now().checked_sub(Duration::from_secs(5));\n```\n\n[`Duration`]: std::time::Duration\n[`Instant::now()`]: std::time::Instant::now;\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.67.0", "applicability": { "is_multi_part_suggestion": false, @@ -9158,7 +9158,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for `unsafe` blocks and impls without a `// SAFETY: ` comment\nexplaining why the unsafe operations performed inside\nthe block are safe.\n\nNote the comment must appear on the line(s) preceding the unsafe block\nwith nothing appearing in between. The following is ok:\n```rust\nfoo(\n // SAFETY:\n // This is a valid safety comment\n unsafe { *x }\n)\n```\nBut neither of these are:\n```rust\n// SAFETY:\n// This is not a valid safety comment\nfoo(\n /* SAFETY: Neither is this */ unsafe { *x },\n);\n```\n\n### Why is this bad?\nUndocumented unsafe blocks and impls can make it difficult to\nread and maintain code, as well as uncover unsoundness\nand bugs.\n\n### Example\n```rust\nuse std::ptr::NonNull;\nlet a = &mut 42;\n\nlet ptr = unsafe { NonNull::new_unchecked(a) };\n```\nUse instead:\n```rust\nuse std::ptr::NonNull;\nlet a = &mut 42;\n\n// SAFETY: references are guaranteed to be non-null.\nlet ptr = unsafe { NonNull::new_unchecked(a) };\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `accept-comment-above-statement`: `bool`(defaults to `true`): Whether to accept a safety comment to be placed above the statement containing the `unsafe` block\n* `accept-comment-above-attributes`: `bool`(defaults to `true`): Whether to accept a safety comment to be placed above the attributes for the `unsafe` block\n", + "docs": "\n### What it does\nChecks for `unsafe` blocks and impls without a `// SAFETY: ` comment\nexplaining why the unsafe operations performed inside\nthe block are safe.\n\nNote the comment must appear on the line(s) preceding the unsafe block\nwith nothing appearing in between. The following is ok:\n```rust\nfoo(\n // SAFETY:\n // This is a valid safety comment\n unsafe { *x }\n)\n```\nBut neither of these are:\n```rust\n// SAFETY:\n// This is not a valid safety comment\nfoo(\n /* SAFETY: Neither is this */ unsafe { *x },\n);\n```\n\n### Why is this bad?\nUndocumented unsafe blocks and impls can make it difficult to\nread and maintain code, as well as uncover unsoundness\nand bugs.\n\n### Example\n```rust\nuse std::ptr::NonNull;\nlet a = &mut 42;\n\nlet ptr = unsafe { NonNull::new_unchecked(a) };\n```\nUse instead:\n```rust\nuse std::ptr::NonNull;\nlet a = &mut 42;\n\n// SAFETY: references are guaranteed to be non-null.\nlet ptr = unsafe { NonNull::new_unchecked(a) };\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `accept-comment-above-statement`: Whether to accept a safety comment to be placed above the statement containing the `unsafe` block (default: `true`)- `accept-comment-above-attributes`: Whether to accept a safety comment to be placed above the attributes for the `unsafe` block (default: `true`)", "version": "1.58.0", "applicability": { "is_multi_part_suggestion": false, @@ -9233,7 +9233,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nDetect when a variable is not inlined in a format string,\nand suggests to inline it.\n\n### Why is this bad?\nNon-inlined code is slightly more difficult to read and understand,\nas it requires arguments to be matched against the format string.\nThe inlined syntax, where allowed, is simpler.\n\n### Example\n```rust\nformat!(\"{}\", var);\nformat!(\"{v:?}\", v = var);\nformat!(\"{0} {0}\", var);\nformat!(\"{0:1$}\", var, width);\nformat!(\"{:.*}\", prec, var);\n```\nUse instead:\n```rust\nformat!(\"{var}\");\nformat!(\"{var:?}\");\nformat!(\"{var} {var}\");\nformat!(\"{var:width$}\");\nformat!(\"{var:.prec$}\");\n```\n\nIf allow-mixed-uninlined-format-args is set to false in clippy.toml,\nthe following code will also trigger the lint:\n```rust\nformat!(\"{} {}\", var, 1+2);\n```\nUse instead:\n```rust\nformat!(\"{var} {}\", 1+2);\n```\n\n### Known Problems\n\nIf a format string contains a numbered argument that cannot be inlined\nnothing will be suggested, e.g. `println!(\"{0}={1}\", var, 1+2)`.\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n* `allow-mixed-uninlined-format-args`: `bool`(defaults to `true`): Whether to allow mixed uninlined format args, e.g. `format!(\"{} {}\", a, foo.bar)`\n", + "docs": "\n### What it does\nDetect when a variable is not inlined in a format string,\nand suggests to inline it.\n\n### Why is this bad?\nNon-inlined code is slightly more difficult to read and understand,\nas it requires arguments to be matched against the format string.\nThe inlined syntax, where allowed, is simpler.\n\n### Example\n```rust\nformat!(\"{}\", var);\nformat!(\"{v:?}\", v = var);\nformat!(\"{0} {0}\", var);\nformat!(\"{0:1$}\", var, width);\nformat!(\"{:.*}\", prec, var);\n```\nUse instead:\n```rust\nformat!(\"{var}\");\nformat!(\"{var:?}\");\nformat!(\"{var} {var}\");\nformat!(\"{var:width$}\");\nformat!(\"{var:.prec$}\");\n```\n\nIf allow-mixed-uninlined-format-args is set to false in clippy.toml,\nthe following code will also trigger the lint:\n```rust\nformat!(\"{} {}\", var, 1+2);\n```\nUse instead:\n```rust\nformat!(\"{var} {}\", 1+2);\n```\n\n### Known Problems\n\nIf a format string contains a numbered argument that cannot be inlined\nnothing will be suggested, e.g. `println!(\"{0}={1}\", var, 1+2)`.\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`- `allow-mixed-uninlined-format-args`: Whether to allow mixed uninlined format args, e.g. `format!(\"{} {}\", a, foo.bar)` (default: `true`)", "version": "1.66.0", "applicability": { "is_multi_part_suggestion": false, @@ -9308,7 +9308,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\n\nChecks for a return type containing a `Box` where `T` implements `Sized`\n\nThe lint ignores `Box` where `T` is larger than `unnecessary_box_size`,\nas returning a large `T` directly may be detrimental to performance.\n\n### Why is this bad?\n\nIt's better to just return `T` in these cases. The caller may not need\nthe value to be boxed, and it's expensive to free the memory once the\n`Box` been dropped.\n\n### Example\n```rust\nfn foo() -> Box {\n Box::new(String::from(\"Hello, world!\"))\n}\n```\nUse instead:\n```rust\nfn foo() -> String {\n String::from(\"Hello, world!\")\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n* `unnecessary-box-size`: `u64`(defaults to `128`): The byte size a `T` in `Box` can have, below which it triggers the `clippy::unnecessary_box` lint\n", + "docs": "\n### What it does\n\nChecks for a return type containing a `Box` where `T` implements `Sized`\n\nThe lint ignores `Box` where `T` is larger than `unnecessary_box_size`,\nas returning a large `T` directly may be detrimental to performance.\n\n### Why is this bad?\n\nIt's better to just return `T` in these cases. The caller may not need\nthe value to be boxed, and it's expensive to free the memory once the\n`Box` been dropped.\n\n### Example\n```rust\nfn foo() -> Box {\n Box::new(String::from(\"Hello, world!\"))\n}\n```\nUse instead:\n```rust\nfn foo() -> String {\n String::from(\"Hello, world!\")\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)- `unnecessary-box-size`: The byte size a `T` in `Box` can have, below which it triggers the `clippy::unnecessary_box` lint (default: `128`)", "version": "1.70.0", "applicability": { "is_multi_part_suggestion": false, @@ -9398,7 +9398,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nAs the counterpart to `or_fun_call`, this lint looks for unnecessary\nlazily evaluated closures on `Option` and `Result`.\n\nThis lint suggests changing the following functions, when eager evaluation results in\nsimpler code:\n - `unwrap_or_else` to `unwrap_or`\n - `and_then` to `and`\n - `or_else` to `or`\n - `get_or_insert_with` to `get_or_insert`\n - `ok_or_else` to `ok_or`\n - `then` to `then_some` (for msrv >= 1.62.0)\n\n### Why is this bad?\nUsing eager evaluation is shorter and simpler in some cases.\n\n### Known problems\nIt is possible, but not recommended for `Deref` and `Index` to have\nside effects. Eagerly evaluating them can change the semantics of the program.\n\n### Example\n```rust\n// example code where clippy issues a warning\nlet opt: Option = None;\n\nopt.unwrap_or_else(|| 42);\n```\nUse instead:\n```rust\nlet opt: Option = None;\n\nopt.unwrap_or(42);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nAs the counterpart to `or_fun_call`, this lint looks for unnecessary\nlazily evaluated closures on `Option` and `Result`.\n\nThis lint suggests changing the following functions, when eager evaluation results in\nsimpler code:\n - `unwrap_or_else` to `unwrap_or`\n - `and_then` to `and`\n - `or_else` to `or`\n - `get_or_insert_with` to `get_or_insert`\n - `ok_or_else` to `ok_or`\n - `then` to `then_some` (for msrv >= 1.62.0)\n\n### Why is this bad?\nUsing eager evaluation is shorter and simpler in some cases.\n\n### Known problems\nIt is possible, but not recommended for `Deref` and `Index` to have\nside effects. Eagerly evaluating them can change the semantics of the program.\n\n### Example\n```rust\n// example code where clippy issues a warning\nlet opt: Option = None;\n\nopt.unwrap_or_else(|| 42);\n```\nUse instead:\n```rust\nlet opt: Option = None;\n\nopt.unwrap_or(42);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.48.0", "applicability": { "is_multi_part_suggestion": false, @@ -9593,7 +9593,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for private functions that only return `Ok` or `Some`.\n\n### Why is this bad?\nIt is not meaningful to wrap values when no `None` or `Err` is returned.\n\n### Known problems\nThere can be false positives if the function signature is designed to\nfit some external requirement.\n\n### Example\n```rust\nfn get_cool_number(a: bool, b: bool) -> Option {\n if a && b {\n return Some(50);\n }\n if a {\n Some(0)\n } else {\n Some(10)\n }\n}\n```\nUse instead:\n```rust\nfn get_cool_number(a: bool, b: bool) -> i32 {\n if a && b {\n return 50;\n }\n if a {\n 0\n } else {\n 10\n }\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n", + "docs": "\n### What it does\nChecks for private functions that only return `Ok` or `Some`.\n\n### Why is this bad?\nIt is not meaningful to wrap values when no `None` or `Err` is returned.\n\n### Known problems\nThere can be false positives if the function signature is designed to\nfit some external requirement.\n\n### Example\n```rust\nfn get_cool_number(a: bool, b: bool) -> Option {\n if a && b {\n return Some(50);\n }\n if a {\n Some(0)\n } else {\n Some(10)\n }\n}\n```\nUse instead:\n```rust\nfn get_cool_number(a: bool, b: bool) -> i32 {\n if a && b {\n return 50;\n }\n if a {\n 0\n } else {\n 10\n }\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)", "version": "1.50.0", "applicability": { "is_multi_part_suggestion": false, @@ -9638,7 +9638,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for unnested or-patterns, e.g., `Some(0) | Some(2)` and\nsuggests replacing the pattern with a nested one, `Some(0 | 2)`.\n\nAnother way to think of this is that it rewrites patterns in\n*disjunctive normal form (DNF)* into *conjunctive normal form (CNF)*.\n\n### Why is this bad?\nIn the example above, `Some` is repeated, which unnecessarily complicates the pattern.\n\n### Example\n```rust\nfn main() {\n if let Some(0) | Some(2) = Some(0) {}\n}\n```\nUse instead:\n```rust\nfn main() {\n if let Some(0 | 2) = Some(0) {}\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for unnested or-patterns, e.g., `Some(0) | Some(2)` and\nsuggests replacing the pattern with a nested one, `Some(0 | 2)`.\n\nAnother way to think of this is that it rewrites patterns in\n*disjunctive normal form (DNF)* into *conjunctive normal form (CNF)*.\n\n### Why is this bad?\nIn the example above, `Some` is repeated, which unnecessarily complicates the pattern.\n\n### Example\n```rust\nfn main() {\n if let Some(0) | Some(2) = Some(0) {}\n}\n```\nUse instead:\n```rust\nfn main() {\n if let Some(0 | 2) = Some(0) {}\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "1.46.0", "applicability": { "is_multi_part_suggestion": false, @@ -9668,7 +9668,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nWarns if a long integral or floating-point constant does\nnot contain underscores.\n\n### Why is this bad?\nReading long numbers is difficult without separators.\n\n### Example\n```rust\n61864918973511\n```\n\nUse instead:\n```rust\n61_864_918_973_511\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `unreadable-literal-lint-fractions`: `bool`(defaults to `true`): Should the fraction of a decimal be linted to include separators.\n", + "docs": "\n### What it does\nWarns if a long integral or floating-point constant does\nnot contain underscores.\n\n### Why is this bad?\nReading long numbers is difficult without separators.\n\n### Example\n```rust\n61864918973511\n```\n\nUse instead:\n```rust\n61_864_918_973_511\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `unreadable-literal-lint-fractions`: Should the fraction of a decimal be linted to include separators. (default: `true`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -9878,7 +9878,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks methods that contain a `self` argument but don't use it\n\n### Why is this bad?\nIt may be clearer to define the method as an associated function instead\nof an instance method if it doesn't require `self`.\n\n### Example\n```rust\nstruct A;\nimpl A {\n fn method(&self) {}\n}\n```\n\nCould be written:\n\n```rust\nstruct A;\nimpl A {\n fn method() {}\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n", + "docs": "\n### What it does\nChecks methods that contain a `self` argument but don't use it\n\n### Why is this bad?\nIt may be clearer to define the method as an associated function instead\nof an instance method if it doesn't require `self`.\n\n### Example\n```rust\nstruct A;\nimpl A {\n fn method(&self) {}\n}\n```\n\nCould be written:\n\n```rust\nstruct A;\nimpl A {\n fn method() {}\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)", "version": "1.40.0", "applicability": { "is_multi_part_suggestion": false, @@ -9956,7 +9956,7 @@ }, "group": "restriction", "level": "allow", - "docs": "\n### What it does\nChecks for `.unwrap()` or `.unwrap_err()` calls on `Result`s and `.unwrap()` call on `Option`s.\n\n### Why is this bad?\nIt is better to handle the `None` or `Err` case,\nor at least call `.expect(_)` with a more helpful message. Still, for a lot of\nquick-and-dirty code, `unwrap` is a good choice, which is why this lint is\n`Allow` by default.\n\n`result.unwrap()` will let the thread panic on `Err` values.\nNormally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `?` operator.\n\nEven if you want to panic on errors, not all `Error`s implement good\nmessages on display. Therefore, it may be beneficial to look at the places\nwhere they may get displayed. Activate this lint to do just that.\n\n### Examples\n```rust\noption.unwrap();\nresult.unwrap();\n```\n\nUse instead:\n```rust\noption.expect(\"more helpful message\");\nresult.expect(\"more helpful message\");\n```\n\nIf [expect_used](#expect_used) is enabled, instead:\n```rust\noption?;\n\n// or\n\nresult?;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `allow-unwrap-in-tests`: `bool`(defaults to `false`): Whether `unwrap` should be allowed in test functions or `#[cfg(test)]`\n\n### Past names\n\n* `option_unwrap_used`\n* `result_unwrap_used`\n\n", + "docs": "\n### What it does\nChecks for `.unwrap()` or `.unwrap_err()` calls on `Result`s and `.unwrap()` call on `Option`s.\n\n### Why is this bad?\nIt is better to handle the `None` or `Err` case,\nor at least call `.expect(_)` with a more helpful message. Still, for a lot of\nquick-and-dirty code, `unwrap` is a good choice, which is why this lint is\n`Allow` by default.\n\n`result.unwrap()` will let the thread panic on `Err` values.\nNormally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `?` operator.\n\nEven if you want to panic on errors, not all `Error`s implement good\nmessages on display. Therefore, it may be beneficial to look at the places\nwhere they may get displayed. Activate this lint to do just that.\n\n### Examples\n```rust\noption.unwrap();\nresult.unwrap();\n```\n\nUse instead:\n```rust\noption.expect(\"more helpful message\");\nresult.expect(\"more helpful message\");\n```\n\nIf [expect_used](#expect_used) is enabled, instead:\n```rust\noption?;\n\n// or\n\nresult?;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `allow-unwrap-in-tests`: Whether `unwrap` should be allowed in test functions or `#[cfg(test)]` (default: `false`)\n### Past names\n\n* `option_unwrap_used`\n* `result_unwrap_used`\n\n", "version": "1.45.0", "applicability": { "is_multi_part_suggestion": false, @@ -9975,7 +9975,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for fully capitalized names and optionally names containing a capitalized acronym.\n\n### Why is this bad?\nIn CamelCase, acronyms count as one word.\nSee [naming conventions](https://rust-lang.github.io/api-guidelines/naming.html#casing-conforms-to-rfc-430-c-case)\nfor more.\n\nBy default, the lint only triggers on fully-capitalized names.\nYou can use the `upper-case-acronyms-aggressive: true` config option to enable linting\non all camel case names\n\n### Known problems\nWhen two acronyms are contiguous, the lint can't tell where\nthe first acronym ends and the second starts, so it suggests to lowercase all of\nthe letters in the second acronym.\n\n### Example\n```rust\nstruct HTTPResponse;\n```\nUse instead:\n```rust\nstruct HttpResponse;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n* `upper-case-acronyms-aggressive`: `bool`(defaults to `false`): Enables verbose mode. Triggers if there is more than one uppercase char next to each other\n", + "docs": "\n### What it does\nChecks for fully capitalized names and optionally names containing a capitalized acronym.\n\n### Why is this bad?\nIn CamelCase, acronyms count as one word.\nSee [naming conventions](https://rust-lang.github.io/api-guidelines/naming.html#casing-conforms-to-rfc-430-c-case)\nfor more.\n\nBy default, the lint only triggers on fully-capitalized names.\nYou can use the `upper-case-acronyms-aggressive: true` config option to enable linting\non all camel case names\n\n### Known problems\nWhen two acronyms are contiguous, the lint can't tell where\nthe first acronym ends and the second starts, so it suggests to lowercase all of\nthe letters in the second acronym.\n\n### Example\n```rust\nstruct HTTPResponse;\n```\nUse instead:\n```rust\nstruct HttpResponse;\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)- `upper-case-acronyms-aggressive`: Enables verbose mode. Triggers if there is more than one uppercase char next to each other (default: `false`)", "version": "1.51.0", "applicability": { "is_multi_part_suggestion": false, @@ -10005,7 +10005,7 @@ }, "group": "nursery", "level": "allow", - "docs": "\n### What it does\nChecks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.\n\n### Why is this bad?\nUnnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.\n\n### Known problems\n- Unaddressed false negative in fn bodies of trait implementations\n\n### Example\n```rust\nstruct Foo;\nimpl Foo {\n fn new() -> Foo {\n Foo {}\n }\n}\n```\ncould be\n```rust\nstruct Foo;\nimpl Foo {\n fn new() -> Self {\n Self {}\n }\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `msrv`: `crate::Msrv`(defaults to `Msrv { stack: [] }`): The minimum rust version that the project supports\n", + "docs": "\n### What it does\nChecks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.\n\n### Why is this bad?\nUnnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.\n\n### Known problems\n- Unaddressed false negative in fn bodies of trait implementations\n\n### Example\n```rust\nstruct Foo;\nimpl Foo {\n fn new() -> Foo {\n Foo {}\n }\n}\n```\ncould be\n```rust\nstruct Foo;\nimpl Foo {\n fn new() -> Self {\n Self {}\n }\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `msrv`: The minimum rust version that the project supports. Defaults to the `rust-version` field in `Cargo.toml`", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -10128,7 +10128,7 @@ }, "group": "perf", "level": "warn", - "docs": "\n### What it does\nChecks for usage of `vec![..]` when using `[..]` would\nbe possible.\n\n### Why is this bad?\nThis is less efficient.\n\n### Example\n```rust\nfn foo(_x: &[u8]) {}\n\nfoo(&vec![1, 2]);\n```\n\nUse instead:\n```rust\nfoo(&[1, 2]);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `too-large-for-stack`: `u64`(defaults to `200`): The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap\n", + "docs": "\n### What it does\nChecks for usage of `vec![..]` when using `[..]` would\nbe possible.\n\n### Why is this bad?\nThis is less efficient.\n\n### Example\n```rust\nfn foo(_x: &[u8]) {}\n\nfoo(&vec![1, 2]);\n```\n\nUse instead:\n```rust\nfoo(&[1, 2]);\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `too-large-for-stack`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (default: `200`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -10143,7 +10143,7 @@ }, "group": "complexity", "level": "warn", - "docs": "\n### What it does\nChecks for usage of `Vec>` where T: Sized anywhere in the code.\nCheck the [Box documentation](https://doc.rust-lang.org/std/boxed/index.html) for more information.\n\n### Why is this bad?\n`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` its contents, you just add another level of indirection.\n\n### Known problems\nVec> makes sense if T is a large type (see [#3530](https://github.com/rust-lang/rust-clippy/issues/3530),\n1st comment).\n\n### Example\n```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n* `vec-box-size-threshold`: `u64`(defaults to `4096`): The size of the boxed type in bytes, where boxing in a `Vec` is allowed\n", + "docs": "\n### What it does\nChecks for usage of `Vec>` where T: Sized anywhere in the code.\nCheck the [Box documentation](https://doc.rust-lang.org/std/boxed/index.html) for more information.\n\n### Why is this bad?\n`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` its contents, you just add another level of indirection.\n\n### Known problems\nVec> makes sense if T is a large type (see [#3530](https://github.com/rust-lang/rust-clippy/issues/3530),\n1st comment).\n\n### Example\n```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)- `vec-box-size-threshold`: The size of the boxed type in bytes, where boxing in a `Vec` is allowed (default: `4096`)", "version": "1.33.0", "applicability": { "is_multi_part_suggestion": false, @@ -10188,7 +10188,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for bit masks that can be replaced by a call\nto `trailing_zeros`\n\n### Why is this bad?\n`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`\n\n### Known problems\nllvm generates better code for `x & 15 == 0` on x86\n\n### Example\n```rust\nif x & 0b1111 == 0 { }\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold`: `u64`(defaults to `1`): The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros'\n", + "docs": "\n### What it does\nChecks for bit masks that can be replaced by a call\nto `trailing_zeros`\n\n### Why is this bad?\n`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`\n\n### Known problems\nllvm generates better code for `x & 15 == 0` on x86\n\n### Example\n```rust\nif x & 0b1111 == 0 { }\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `verbose-bit-mask-threshold`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (default: `1`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false, @@ -10308,7 +10308,7 @@ }, "group": "pedantic", "level": "allow", - "docs": "\n### What it does\nChecks for wildcard imports `use _::*`.\n\n### Why is this bad?\nwildcard imports can pollute the namespace. This is especially bad if\nyou try to import something through a wildcard, that already has been imported by name from\na different source:\n\n```rust\nuse crate1::foo; // Imports a function named foo\nuse crate2::*; // Has a function named foo\n\nfoo(); // Calls crate1::foo\n```\n\nThis can lead to confusing error messages at best and to unexpected behavior at worst.\n\n### Exceptions\nWildcard imports are allowed from modules that their name contains `prelude`. Many crates\n(including the standard library) provide modules named \"prelude\" specifically designed\nfor wildcard import.\n\n`use super::*` is allowed in test modules. This is defined as any module with \"test\" in the name.\n\nThese exceptions can be disabled using the `warn-on-all-wildcard-imports` configuration flag.\n\n### Known problems\nIf macros are imported through the wildcard, this macro is not included\nby the suggestion and has to be added by hand.\n\nApplying the suggestion when explicit imports of the things imported with a glob import\nexist, may result in `unused_imports` warnings.\n\n### Example\n```rust\nuse crate1::*;\n\nfoo();\n```\n\nUse instead:\n```rust\nuse crate1::foo;\n\nfoo();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `warn-on-all-wildcard-imports`: `bool`(defaults to `false`): Whether to allow certain wildcard imports (prelude, super in tests).\n", + "docs": "\n### What it does\nChecks for wildcard imports `use _::*`.\n\n### Why is this bad?\nwildcard imports can pollute the namespace. This is especially bad if\nyou try to import something through a wildcard, that already has been imported by name from\na different source:\n\n```rust\nuse crate1::foo; // Imports a function named foo\nuse crate2::*; // Has a function named foo\n\nfoo(); // Calls crate1::foo\n```\n\nThis can lead to confusing error messages at best and to unexpected behavior at worst.\n\n### Exceptions\nWildcard imports are allowed from modules that their name contains `prelude`. Many crates\n(including the standard library) provide modules named \"prelude\" specifically designed\nfor wildcard import.\n\n`use super::*` is allowed in test modules. This is defined as any module with \"test\" in the name.\n\nThese exceptions can be disabled using the `warn-on-all-wildcard-imports` configuration flag.\n\n### Known problems\nIf macros are imported through the wildcard, this macro is not included\nby the suggestion and has to be added by hand.\n\nApplying the suggestion when explicit imports of the things imported with a glob import\nexist, may result in `unused_imports` warnings.\n\n### Example\n```rust\nuse crate1::*;\n\nfoo();\n```\n\nUse instead:\n```rust\nuse crate1::foo;\n\nfoo();\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `warn-on-all-wildcard-imports`: Whether to allow certain wildcard imports (prelude, super in tests). (default: `false`)", "version": "1.43.0", "applicability": { "is_multi_part_suggestion": false, @@ -10398,7 +10398,7 @@ }, "group": "style", "level": "warn", - "docs": "\n### What it does\nChecks for methods with certain name prefixes or suffixes, and which\ndo not adhere to standard conventions regarding how `self` is taken.\nThe actual rules are:\n\n|Prefix |Postfix |`self` taken | `self` type |\n|-------|------------|-------------------------------|--------------|\n|`as_` | none |`&self` or `&mut self` | any |\n|`from_`| none | none | any |\n|`into_`| none |`self` | any |\n|`is_` | none |`&mut self` or `&self` or none | any |\n|`to_` | `_mut` |`&mut self` | any |\n|`to_` | not `_mut` |`self` | `Copy` |\n|`to_` | not `_mut` |`&self` | not `Copy` |\n\nNote: Clippy doesn't trigger methods with `to_` prefix in:\n- Traits definition.\nClippy can not tell if a type that implements a trait is `Copy` or not.\n- Traits implementation, when `&self` is taken.\nThe method signature is controlled by the trait and often `&self` is required for all types that implement the trait\n(see e.g. the `std::string::ToString` trait).\n\nClippy allows `Pin<&Self>` and `Pin<&mut Self>` if `&self` and `&mut self` is required.\n\nPlease find more info here:\nhttps://rust-lang.github.io/api-guidelines/naming.html#ad-hoc-conversions-follow-as_-to_-into_-conventions-c-conv\n\n### Why is this bad?\nConsistency breeds readability. If you follow the\nconventions, your users won't be surprised that they, e.g., need to supply a\nmutable reference to a `as_..` function.\n\n### Example\n```rust\nimpl X {\n fn as_str(self) -> &'static str {\n // ..\n }\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n* `avoid-breaking-exported-api`: `bool`(defaults to `true`): Suppress lints whenever the suggested change would cause breakage for other crates.\n", + "docs": "\n### What it does\nChecks for methods with certain name prefixes or suffixes, and which\ndo not adhere to standard conventions regarding how `self` is taken.\nThe actual rules are:\n\n|Prefix |Postfix |`self` taken | `self` type |\n|-------|------------|-------------------------------|--------------|\n|`as_` | none |`&self` or `&mut self` | any |\n|`from_`| none | none | any |\n|`into_`| none |`self` | any |\n|`is_` | none |`&mut self` or `&self` or none | any |\n|`to_` | `_mut` |`&mut self` | any |\n|`to_` | not `_mut` |`self` | `Copy` |\n|`to_` | not `_mut` |`&self` | not `Copy` |\n\nNote: Clippy doesn't trigger methods with `to_` prefix in:\n- Traits definition.\nClippy can not tell if a type that implements a trait is `Copy` or not.\n- Traits implementation, when `&self` is taken.\nThe method signature is controlled by the trait and often `&self` is required for all types that implement the trait\n(see e.g. the `std::string::ToString` trait).\n\nClippy allows `Pin<&Self>` and `Pin<&mut Self>` if `&self` and `&mut self` is required.\n\nPlease find more info here:\nhttps://rust-lang.github.io/api-guidelines/naming.html#ad-hoc-conversions-follow-as_-to_-into_-conventions-c-conv\n\n### Why is this bad?\nConsistency breeds readability. If you follow the\nconventions, your users won't be surprised that they, e.g., need to supply a\nmutable reference to a `as_..` function.\n\n### Example\n```rust\nimpl X {\n fn as_str(self) -> &'static str {\n // ..\n }\n}\n```\n\n### Configuration\nThis lint has the following configuration variables:\n\n- `avoid-breaking-exported-api`: Suppress lints whenever the suggested change would cause breakage for other crates. (default: `true`)", "version": "pre 1.29.0", "applicability": { "is_multi_part_suggestion": false,