diff --git a/current b/current deleted file mode 120000 index ec24c6a3f709..000000000000 --- a/current +++ /dev/null @@ -1 +0,0 @@ -v0.0.212 \ No newline at end of file diff --git a/list/index.html b/rust-1.29.0/index.html similarity index 87% rename from list/index.html rename to rust-1.29.0/index.html index 6892857af4e9..e11f2eeba3b3 100644 --- a/list/index.html +++ b/rust-1.29.0/index.html @@ -4,7 +4,7 @@ - Clippy + ALL the Clippy Lints @@ -14,6 +14,9 @@ .form-inline .checkbox { margin-right: 0.6em } + .panel-heading { cursor: pointer; } + .panel-heading:hover { background-color: #eee; } + .panel-title { display: flex; } .panel-title .label { display: inline-block; } @@ -73,8 +76,8 @@

ALL the Clippy Lints

- Filter: - + +
- + Fork me on Github @@ -164,6 +167,19 @@

}); } + function selectGroup($scope, selectedGroup) { + var groups = $scope.groups; + for (var group in groups) { + if (groups.hasOwnProperty(group)) { + if (group === selectedGroup) { + groups[group] = true; + } else { + groups[group] = false; + } + } + } + } + angular.module("clippy", []) .filter('markdown', function ($sce) { return function (text) { @@ -220,6 +236,11 @@

return result; }, {}); + var selectedGroup = getQueryVariable("sel"); + if (selectedGroup) { + selectGroup($scope, selectedGroup.toLowerCase()); + } + scrollToLintByURL($scope); }) .error(function (data) { @@ -240,6 +261,17 @@

}, false); }); })(); + + function getQueryVariable(variable) { + var query = window.location.search.substring(1); + var vars = query.split('&'); + for (var i = 0; i < vars.length; i++) { + var pair = vars[i].split('='); + if (decodeURIComponent(pair[0]) == variable) { + return decodeURIComponent(pair[1]); + } + } + } diff --git a/list/lints.json b/rust-1.29.0/lints.json similarity index 57% rename from list/lints.json rename to rust-1.29.0/lints.json index 04bb707e0a9c..e5e519579e02 100644 --- a/list/lints.json +++ b/rust-1.29.0/lints.json @@ -1,3085 +1,3085 @@ [ { - "docs": { - "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", - "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", - "Example": "```rust\nfn x() -> Option> {\n None\n}", - "Known problems": "None." - }, - "group": "complexity", - "id": "option_option", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for `for` loops over `Option` values.", - "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", - "Example": "```rust\nfor x in option { .. }\n```\n\nThis should be\n```rust\nif let Some(x) = option { .. }\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "for_loop_over_option", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", - "Why is this bad": "`.push_str(s)` is clearer", - "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```", - "Known problems": "None." - }, - "group": "style", - "id": "string_extend_chars", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", - "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", - "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1", - "Known problems": "None." - }, - "group": "complexity", - "id": "precedence", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for empty lines after outer attributes", - "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", - "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```", - "Known problems": "Can cause false positives.\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect." - }, - "group": "nursery", - "id": "empty_line_after_outer_attr", - "level": "Allow" - }, - { - "docs": { - "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", - "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", - "Example": "```rust\n618_64_9189_73_511\n```", - "Known problems": "None." - }, - "group": "style", - "id": "inconsistent_digit_grouping", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of `.clone()` on an `&&T`.", - "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", - "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\",*y, z); // prints out the same pointer\n}\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "clone_double_ref", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", - "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", - "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```", - "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925" - }, - "group": "pedantic", - "id": "expl_impl_clone_on_copy", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", - "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", - "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "result_map_unwrap_or_else", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", - "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", - "Example": "```rust\nstruct Foo {}\nimpl Foo {\n fn new() -> Foo {\n Foo {}\n }\n}\n```\ncould be\n```\nstruct Foo {}\nimpl Foo {\n fn new() -> Self {\n Self {}\n }\n}\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "use_self", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for matches with a two arms where an `if let` will\nusually suffice.", - "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", - "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```", - "Known problems": "Personal style preferences may differ." - }, - "group": "pedantic", - "id": "single_match_else", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for incompatible bit masks in comparisons.\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", - "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", - "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "bad_bit_mask", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", - "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", - "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "drop_ref", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", - "Why is this bad": "`const fn`s exist", - "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "replace_consts", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", - "Why is this bad": "It makes the code less readable.", - "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "match_bool", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for loops on `x.next()`.", - "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", - "Example": "```rust\nfor x in y.next() { .. }\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "iter_next_loop", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks to see if multiple versions of a crate are being\nused.", - "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", - "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```", - "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue." - }, - "group": "cargo", - "id": "multiple_crate_versions", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for usage of `unimplemented!`.", - "Why is this bad": "This macro should not be present in production code", - "Example": "```rust\nunimplemented!();\n```", - "Known problems": "None." - }, - "group": "restriction", - "id": "unimplemented", - "level": "Allow" - }, - { - "docs": { - "What it does": "Detects closures called in the same expression where they\nare defined.", - "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", - "Example": "```rust\n(|| 42)()\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "redundant_closure_call", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", - "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", - "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "deprecated_semver", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", - "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\nThe `const` value should be stored inside a `static` item.", - "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```", - "Known problems": "None" - }, - "group": "correctness", - "id": "borrow_interior_mutable_const", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for `.unwrap()` calls on `Option`s.", - "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", - "Example": "```rust\nx.unwrap()\n```", - "Known problems": "None." - }, - "group": "restriction", - "id": "option_unwrap_used", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for compound assignment operations (`+=` and\nsimilar).", - "Why is this bad": "Projects with many developers from languages without\nthose operations may find them unreadable and not worth their weight.", - "Example": "```rust\na += 1;\n```", - "Known problems": "Types implementing `OpAssign` don't necessarily\nimplement `Op`." - }, - "group": "restriction", - "id": "assign_ops", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", - "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", - "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```", - "Known problems": "https://github.com/rust-lang-nursery/rust-clippy/issues/886" - }, - "group": "pedantic", - "id": "invalid_upcast_comparisons", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for the use of bindings with a single leading\nunderscore.", - "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", - "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```", - "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time." - }, - "group": "pedantic", - "id": "used_underscore_binding", - "level": "Allow" - }, - { - "docs": { - "What it does": "This lint checks for equality comparisons with `ptr::null`", - "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", - "Example": "```rust\nif x == ptr::null { .. }\n```", - "Known problems": "None." - }, - "group": "style", - "id": "cmp_null", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", - "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", - "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "option_map_unit_fn", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", - "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", - "Example": "```rust\nlet x = x + 1;\n```", - "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns." - }, - "group": "restriction", - "id": "shadow_reuse", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", - "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", - "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```", - "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates." - }, - "group": "style", - "id": "implicit_hasher", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", - "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", - "Example": "```rust\npub fn foo(x: *const u8) { println!(\"{}\", unsafe { *x }); }\n```", - "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`)." - }, - "group": "correctness", - "id": "not_unsafe_ptr_arg_deref", - "level": "Deny" - }, - { - "docs": { - "What it does": "Detects classic underflow/overflow checks.", - "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", - "Example": "```rust\na + b < a\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "overflow_check_conditional", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for structure field patterns bound to wildcards.", - "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", - "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```", - "Known problems": "None." - }, - "group": "style", - "id": "unneeded_field_pattern", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for types with a `fn new() -> Self` method\nand no implementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html),\nwhere the `Default` can be derived by `#[derive(Default)]`.", - "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", - "Example": "```rust,ignore\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nJust prepend `#[derive(Default)]` before the `struct` definition.", - "Known problems": "Hopefully none." - }, - "group": "style", - "id": "new_without_default_derive", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", - "Why is this bad": "This is most likely a logic bug.", - "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`.", - "Known problems": "Ignores short circuiting behavior." - }, - "group": "correctness", - "id": "logic_bug", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", - "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", - "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "nonsensical_open_options", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for transmutes from a pointer to a reference.", - "Why is this bad": "This can always be rewritten with `&` and `*`.", - "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n// can be written:\nlet _: &T = &*p;\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "transmute_ptr_to_ref", - "level": "Warn" - }, - { - "docs": { - "What it does": "Catch casts from `0` to some pointer type", - "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", - "Example": "```rust\n0 as *const u32\n```", - "Known problems": "None." - }, - "group": "style", - "id": "zero_ptr", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", - "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", - "Example": "```rust\nname.chars().next() == Some('_')\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "chars_next_cmp", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", - "Why is this bad": "It is not as fast as a memcpy.", - "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```", - "Known problems": "None." - }, - "group": "perf", - "id": "manual_memcpy", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", - "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", - "Example": "```rust\nprintln!(\"Hello world!\");\n```", - "Known problems": "Only catches `print!` and `println!` calls." - }, - "group": "restriction", - "id": "print_stdout", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", - "Why is this bad": "Not every byte slice is a valid UTF-8 string.", - "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```", - "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html" - }, - "group": "complexity", - "id": "transmute_bytes_to_str", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usages of `Mutex` where an atomic will do.", - "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::atomic::AtomicBool` and `std::atomic::AtomicPtr` are leaner and\nfaster.", - "Example": "```rust\nlet x = Mutex::new(&y);\n```", - "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section." - }, - "group": "perf", - "id": "mutex_atomic", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", - "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", - "Example": "```rust\nloop { ..; break; }\n```", - "Known problems": "None" - }, - "group": "correctness", - "id": "never_loop", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for iteration that may be infinite.", - "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", - "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```", - "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it." - }, - "group": "pedantic", - "id": "maybe_infinite_iter", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", - "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", - "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```", - "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed." - }, - "group": "correctness", - "id": "declare_interior_mutable_const", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", - "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", - "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `).", - "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", - "Known problems": "None." - }, - "group": "perf", - "id": "boxed_local", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for always-identical `Into`/`From` conversions.", - "Why is this bad": "Redundant code.", - "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "identity_conversion", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for `foo = bar; bar = foo` sequences.", - "Why is this bad": "This looks like a failed attempt to swap.", - "Example": "```rust,ignore\na = b;\nb = a;\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "almost_swapped", - "level": "Deny" - }, - { - "docs": { - "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", - "Why is this bad": "Negatively impacts readability.", - "Example": "```rust\n6186491_8973511\n```", - "Known problems": "None." - }, - "group": "style", - "id": "large_digit_groups", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for multiple inherent implementations of a struct", - "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", - "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```", - "Known problems": "None." - }, - "group": "restriction", - "id": "multiple_inherent_impl", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", - "Why is this bad": "This could lead to unexpected results.", - "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "possible_missing_comma", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", - "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::atomic::usize` is leaner and faster.", - "Example": "```rust\nlet x = Mutex::new(0usize);\n```", - "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section." - }, - "group": "nursery", - "id": "mutex_integer", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", - "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable. Also creates a new heap allocation and throws\naway the old one.", - "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "string_add_assign", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", - "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", - "Example": "```rust\nlet x = y; let x = z; // shadows the earlier binding\n```", - "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns." - }, - "group": "restriction", - "id": "shadow_unrelated", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", - "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", - "Example": "```rust\nfn foo(ref x: u8) -> bool { .. }\n```", - "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function." - }, - "group": "style", - "id": "toplevel_ref_arg", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", - "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", - "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "cast_sign_loss", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", - "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", - "Example": "```rust\nregex!(\"foo|bar\")\n```", - "Known problems": "None." - }, - "group": "style", - "id": "regex_macro", - "level": "Warn" - }, - { - "docs": { - "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", - "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", - "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```", - "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway." - }, - "group": "correctness", - "id": "mut_from_ref", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for `0.0 / 0.0`.", - "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", - "Example": "```rust\n0.0f32 / 0.0\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "zero_divided_by_zero", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for transmutes between a type `T` and `*T`.", - "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", - "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n// `*t` or `&t`'s\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "crosspointer_transmute", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for expressions that could be replaced by the question mark operator", - "Why is this bad": "Question mark usage is more idiomatic", - "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```", - "Known problems": "None" - }, - "group": "style", - "id": "question_mark", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", - "Why is this bad": "It's basically guaranteed to be undefined behaviour.", - "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```", - "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation." - }, - "group": "correctness", - "id": "wrong_transmute", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for `match` with identical arm bodies.", - "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", - "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```", - "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang-nursery/rust-clippy/issues/860))." - }, - "group": "pedantic", - "id": "match_same_arms", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for usage of `_.map_or(None, _)`.", - "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", - "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```", - "Known problems": "The order of the arguments is not in execution order." - }, - "group": "style", - "id": "option_map_or_none", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for use of `Box>` anywhere in the code.", - "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", - "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```", - "Known problems": "None." - }, - "group": "perf", - "id": "box_vec", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", - "Why is this bad": ": Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust,ignore\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for compound assignment operations (`+=` and\nsimilar).", + "Why is this bad": "Projects with many developers from languages without\nthose operations may find them unreadable and not worth their weight.", + "Known problems": "Types implementing `OpAssign` don't necessarily\nimplement `Op`.", + "Example": "```rust\na += 1;\n```" + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } ..\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true` (or vice\nversa) and suggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true { } // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 { x as u64 }\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 { u64::from(x) }\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 { x as u8 }\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX; x as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\",*y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", + "Why is this bad": ": Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", "Example": "```rust\nx.clone()\n```" - }, - "group": "restriction", - "id": "clone_on_ref_ptr", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", - "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", - "Example": "```rust\nmem::forget(Rc::new(55)))\n```", - "Known problems": "None." - }, - "group": "restriction", - "id": "mem_forget", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", - "Why is this bad": "This will lead to a runtime panic.", - "Example": "```rust\nRegex::new(\"|\")\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "invalid_regex", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", - "Why is this bad": "The call is unnecessary.", - "Example": "```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x);\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "useless_asref", - "level": "Warn" - }, - { - "docs": { - "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", - "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", - "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "pub_enum_variant_names", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", - "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", - "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```", - "Known problems": "None." - }, - "group": "style", - "id": "get_unwrap", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for mis-uses of the serde API.", - "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", - "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`.", - "Known problems": "None." - }, - "group": "correctness", - "id": "serde_api_misuse", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", - "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", - "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`.", - "Known problems": "None." - }, - "group": "style", - "id": "redundant_closure", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", - "Why is this bad": "This is usually just a typo or a copy and paste error.", - "Example": "```rust\nx + 1 == x + 1\n```", - "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future." - }, - "group": "correctness", - "id": "eq_op", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", - "Why is this bad": "The code is better expressed with `.enumerate()`.", - "Example": "```rust\nx.iter().zip(0..x.len())\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "range_zip_with_len", - "level": "Warn" - }, - { - "docs": { - "What it does": "Nothing. This lint has been deprecated.", - "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." - }, - "group": "deprecated", - "id": "unstable_as_mut_slice", - "level": "Deprecated" - }, - { - "docs": { - "What it does": "Checks for useless borrowed references.", - "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", - "Example": "```rust\n let mut v = Vec::::new();\n let _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()", - "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways" - }, - "group": "complexity", - "id": "needless_borrowed_reference", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", - "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", - "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "match_ref_pats", - "level": "Warn" - }, - { - "docs": { - "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", - "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", - "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str { .. }\n}\n```", - "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users." - }, - "group": "restriction", - "id": "wrong_pub_self_convention", - "level": "Allow" - }, - { - "docs": { - "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", - "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", - "Example": "```rust\nfn foo(&Vec) { .. }\n```", - "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case." - }, - "group": "style", - "id": "ptr_arg", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", - "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", - "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "derive_hash_xor_eq", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes", - "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was\nforgotten", - "Example": "```rust\n#[deny(dead_code)]\nextern crate foo;\n#[allow(unused_import)]\nuse foo::bar;\n```", - "Known problems": "Technically one might allow `unused_import` on a `use`\nitem,\nbut it's easier to remove the unused item." - }, - "group": "correctness", - "id": "useless_attribute", - "level": "Deny" - }, - { - "docs": { - "What it does": "Nothing. This lint has been deprecated.", - "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." - }, - "group": "deprecated", - "id": "string_to_string", - "level": "Deprecated" - }, - { - "docs": { - "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", - "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", - "Example": "```rust\n(0, 0).0 = 1\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "temporary_assignment", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", - "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", - "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```", - "Known problems": "Hopefully none." - }, - "group": "pedantic", - "id": "indexing_slicing", - "level": "Allow" - }, - { - "docs": { - "What it does": "Nothing. This lint has been deprecated.", - "Deprecation reason": "This used to check for `assert!(a == b)` and recommend\nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." - }, - "group": "deprecated", - "id": "should_assert_eq", - "level": "Deprecated" - }, - { - "docs": { - "What it does": "Checks for `#[inline]` on trait methods without bodies", - "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", - "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "inline_fn_without_body", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", - "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", - "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```", - "Known problems": "None." - }, - "group": "style", - "id": "chars_last_cmp", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", - "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", - "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "short_circuit_statement", - "level": "Warn" - }, - { - "docs": { - "What it does": "Nothing. This lint has been deprecated.", - "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." - }, - "group": "deprecated", - "id": "unstable_as_slice", - "level": "Deprecated" - }, - { - "docs": { - "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", - "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", - "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `).", - "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "enum_variant_names", - "level": "Warn" - }, - { - "docs": { - "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", - "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", - "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```", - "Known problems": "Sometimes the wrong binding is displayed (#383)." - }, - "group": "complexity", - "id": "while_let_loop", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", - "Why is this bad": "These can be written as the shorter `a op= b`.", - "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```", - "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl." - }, - "group": "style", - "id": "assign_op_pattern", - "level": "Warn" - }, - { - "docs": { - "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", - "Why is this bad": "It looks confusing.", - "Example": "```rust\nlet y = 0x1a9BAcD;\n```", - "Known problems": "None." - }, - "group": "style", - "id": "mixed_case_hex_literals", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", - "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", - "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```", - "Known problems": "The order of the arguments is not in execution order." - }, - "group": "pedantic", - "id": "option_map_unwrap_or_else", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for items declared after some statement in a block.", - "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", - "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "items_after_statements", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", - "Why is this bad": "Consistency 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.", - "Example": "```rust\nimpl X {\n fn as_str(self) -> &str { .. }\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "wrong_self_convention", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", - "Why is this bad": "These names are usually placeholder names and should be\navoided.", - "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `).", - "Example": "```rust\nlet foo = 3.14;\n```", - "Known problems": "None." - }, - "group": "style", - "id": "blacklisted_name", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for casts of a function pointer to a numeric type not enough to store address.", - "Why is this bad": "Casting a function pointer to not eligable type could truncate the address value.", - "Example": "```rust\nfn test_fn() -> i16;\nlet _ = test_fn as i32\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "fn_to_numeric_cast_with_truncation", - "level": "Deny" - }, - { - "docs": { - "What it does": "Detects expressions of the form `--x`.", - "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", - "Example": "```rust\n--x;\n```", - "Known problems": "None." - }, - "group": "style", - "id": "double_neg", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", - "Why is this bad": "Readability.", - "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```", - "Known problems": "None." - }, - "group": "style", - "id": "unnecessary_fold", - "level": "Warn" - }, - { - "docs": { - "What it does": "Nothing. This lint has been deprecated.", + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\nx == NAN\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```rust\nif x == ptr::null { .. }\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```rust\nconst 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```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n// `*t` or `&t`'s\n```" + } + }, + { + "id": "cyclomatic_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cyclomatic complexity.", + "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simpified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```rust\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nx + 1 == x + 1\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g. `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\n0 / x; 0 * x; x & 0\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {x = 1; 1} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n let v: f32 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789\n\n// Good\n let v: f64 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.unwrap_or_else(|_| panic!(format(\"Err {}: {}\", err_code, err_msg).as_str()))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() { .. }\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() { .. }\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." - }, - "group": "deprecated", - "id": "extend_from_slice", - "level": "Deprecated" - }, - { - "docs": { - "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", - "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", - "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "partialeq_ne_impl", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", - "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", - "Example": "```rust\nfor x..=(y-1) { .. }\n```", - "Known problems": "None." - }, - "group": "style", - "id": "range_minus_one", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for float arithmetic.", - "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", - "Example": "```rust\na + 1.0\n```", - "Known problems": "None." - }, - "group": "restriction", - "id": "float_arithmetic", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for `enum`s with no variants.", - "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", - "Example": "```rust\nenum Test {}\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "empty_enum", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", - "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", - "Example": "`_.split(\"x\")` could be `_.split('x')", - "Known problems": "Does not catch multi-byte unicode characters." - }, - "group": "perf", - "id": "single_char_pattern", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for overlapping match arms.", - "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", - "Example": "```rust\nlet x = 5;\nmatch x {\n 1 ... 10 => println!(\"1 ... 10\"),\n 5 ... 15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "match_overlapping_arm", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", - "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", - "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```", - "Known problems": "None." - }, - "group": "restriction", - "id": "string_add", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", - "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", - "Example": "```rust\ncompute_array()[0];\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "unnecessary_operation", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", - "Why is this bad": "Rust will truncate the literal silently.", - "Example": "```rust\n// Bad\n let v: f32 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789\n\n// Good\n let v: f64 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789_9\n```", - "Known problems": "None." - }, - "group": "style", - "id": "excessive_precision", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for methods with high cyclomatic complexity.", - "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", - "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `).", - "Example": "No. You'll see it when you get the warning.", - "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity." - }, - "group": "complexity", - "id": "cyclomatic_complexity", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", - "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", - "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```", - "Known problems": "None." - }, - "group": "restriction", - "id": "else_if_without_else", - "level": "Allow" - }, - { - "docs": { - "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", - "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", - "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```", - "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`." - }, - "group": "style", - "id": "print_literal", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", - "Why is this bad": "It affects code readability.", - "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "duplicate_underscore_argument", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", - "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", - "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`.", - "Known problems": "None" - }, - "group": "correctness", - "id": "min_max", - "level": "Deny" - }, - { - "docs": { - "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", - "Why is this bad": "You should use `println!()`, which is simpler.", - "Example": "```rust\nprintln!(\"\");\n```", - "Known problems": "None." - }, - "group": "style", - "id": "println_empty_string", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", - "Why is this bad": "This is less efficient.", - "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```", - "Known problems": "None." - }, - "group": "perf", - "id": "useless_vec", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", - "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", - "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\ncall_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "temporary_cstring_as_ptr", - "level": "Deny" - }, - { - "docs": { - "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", - "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", - "Example": "```rust\nwriteln!(\"\");\n```", - "Known problems": "None." - }, - "group": "style", - "id": "writeln_empty_string", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", - "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", - "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```", - "Known problems": "None." - }, - "group": "style", - "id": "infallible_destructuring_match", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", - "Why is this bad": "*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.", - "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n ] `).", - "Examples": "```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) { .. }\n```", - "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives." - }, - "group": "pedantic", - "id": "doc_markdown", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", - "Why is this bad": "Using blocks in the condition makes it hard to read.", - "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```", - "Known problems": "None." - }, - "group": "style", - "id": "block_in_if_condition_stmt", - "level": "Warn" - }, - { - "docs": { - "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", - "Why is this bad": "Reading long numbers is difficult without separators.", - "Example": "```rust\n61864918973511\n```", - "Known problems": "None." - }, - "group": "style", - "id": "unreadable_literal", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", - "Why is this bad": "Using `entry` is more efficient.", - "Example": "```rust\nif !m.contains_key(&k) { m.insert(k, v) }\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```", - "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) { m.insert(k.clone(), v); }\n```" - }, - "group": "perf", - "id": "map_entry", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", - "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", - "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "useless_transmute", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", - "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", - "Example": "```rust\nx.to_owned() == y\n```", - "Known problems": "None." - }, - "group": "perf", - "id": "cmp_owned", - "level": "Warn" - }, - { - "docs": { - "What it does": "Warns if a generic shadows a built-in type.", - "Why is this bad": "This gives surprising type errors.", - "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "builtin_type_shadow", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for erasing operations, e.g. `x * 0`.", - "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", - "Example": "```rust\n0 / x; 0 * x; x & 0\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "erasing_op", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for literal calls to `Default::default()`.", - "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", - "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "default_trait_access", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for comparisons to NaN.", - "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", - "Example": "```rust\nx == NAN\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "cmp_nan", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", - "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", - "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "float_cmp", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for identity operations, e.g. `x + 0`.", - "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", - "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "identity_op", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for the Unicode zero-width space in the code.", - "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", - "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text.", - "Known problems": "None." - }, - "group": "correctness", - "id": "zero_width_space", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for multiplication by -1 as a form of negation.", - "Why is this bad": "It's more readable to just negate.", - "Example": "```rust\nx * -1\n```", - "Known problems": "This only catches integers (for now)." - }, - "group": "style", - "id": "neg_multiply", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", - "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", - "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "explicit_counter_loop", - "level": "Warn" - }, - { - "docs": { - "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", - "Why is this bad": "Doc 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.", - "Known problems": "None." - }, - "group": "restriction", - "id": "missing_docs_in_private_items", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for constants with an explicit `'static` lifetime.", - "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", - "Example": "```rust\nconst 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```", - "Known problems": "None." - }, - "group": "style", - "id": "const_static_lifetime", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", - "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", - "Example": "```rust\nPoint { x: 1, y: 0, ..zero_point }\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "needless_update", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", - "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", - "Example": "```rust\nfn as_u8(x: u64) -> u8 { x as u8 }\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "cast_possible_truncation", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for `while let` expressions on iterators.", - "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", - "Example": "```rust\nwhile let Some(val) = iter() { .. }\n```", - "Known problems": "None." - }, - "group": "style", - "id": "while_let_on_iterator", - "level": "Warn" - }, - { - "docs": { - "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", - "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make sense.\nIt allows the crate to require all exported methods to be `#[inline]` by default, and then opt\nout for specific methods where this might not make sense.", - "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```", - "Known problems": "None." - }, - "group": "restriction", - "id": "missing_inline_in_public_items", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", - "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", - "Example": "```rust\niter.find(|x| x == 0).is_some()\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "search_is_some", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", - "Why is this bad": "There is no point of doing that. `format!(\"too\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", - "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "useless_format", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for plain integer arithmetic.", - "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", - "Example": "```rust\na + 1\n```", - "Known problems": "None." - }, - "group": "restriction", - "id": "integer_arithmetic", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", - "Why is this bad": "Readability.", - "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() { .. }\n```", - "Known problems": "False negatives. We currently only warn on some known\ntypes." - }, - "group": "style", - "id": "explicit_iter_loop", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", - "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", - "Example": "```rust\nlet x = &x;\n```", - "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns." - }, - "group": "restriction", - "id": "shadow_same", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for diverging calls that are not match arms or\nstatements.", - "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", - "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```", - "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand." - }, - "group": "complexity", - "id": "diverging_sub_expression", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", - "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", - "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" - }, - "group": "restriction", - "id": "use_debug", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", - "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", - "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "transmute_ptr_to_ptr", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", - "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", - "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => ()\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "single_match", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for naive byte counts", - "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", - "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```", - "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases." - }, - "group": "perf", - "id": "naive_bytecount", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", - "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", - "Example": "```rust\nfor x in (5..5).step_by(0) { .. }\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "iterator_step_by_zero", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", - "Why is this bad": "It is more idiomatic to dereference the other argument.", - "Example": "```rust\n&x == y\n```", - "Known problems": "None" - }, - "group": "style", - "id": "op_ref", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", - "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", - "Example": "```rust\nfor (k, _) in &map { .. }\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() { .. }\n```", - "Known problems": "None." - }, - "group": "style", - "id": "for_kv_map", - "level": "Warn" - }, - { - "docs": { - "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", - "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", - "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```", - "Known problems": "None." - }, - "group": "style", - "id": "print_with_newline", - "level": "Warn" - }, - { - "docs": { - "What it does": "* Checks for unnecessary `ok()` in if let.", - "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", - "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "if_let_some_result", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for transmutes from an integer to a `char`.", - "Why is this bad": "Not every integer is a Unicode scalar value.", - "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```", - "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html" - }, - "group": "complexity", - "id": "transmute_int_to_char", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", - "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", - "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```", - "Known problems": "None." - }, - "group": "perf", - "id": "iter_nth", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", - "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", - "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "collapsible_if", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", - "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", - "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `).", - "Example": "```rust\nstruct Foo { inner: Rc>>> }\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "type_complexity", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", - "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", - "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize { .. }\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "len_without_is_empty", - "level": "Warn" - }, - { - "docs": { - "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", - "Why is this bad": "It is much less readable.", - "Example": "```rust\nlet y = 123832i32;\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "unseparated_literal_suffix", - "level": "Allow" - }, - { - "docs": { - "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", - "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", - "Example": "```rust\nmy_vec.push(&mut value)\n```", - "Known problems": "None." - }, - "group": "style", - "id": "unnecessary_mut_passed", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", - "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", - "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `).", - "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", - "Known problems": "This 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.\nThe configuration option `trivial_copy_size_limit` can be set to override\nthis limit for a project." - }, - "group": "perf", - "id": "trivially_copy_pass_by_ref", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", - "Why is this bad": "This is not idiomatic Rust.", - "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```", - "Known problems": "None." - }, - "group": "style", - "id": "useless_let_if_seq", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for boolean expressions that can be written more\nconcisely.", - "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", - "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```", - "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`." - }, - "group": "complexity", - "id": "nonminimal_bool", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for `new` not returning `Self`.", - "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", - "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "new_ret_no_self", - "level": "Warn" - }, - { - "docs": { - "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", - "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", - "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "suspicious_arithmetic_impl", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks 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.", - "Why is this bad": "Usually, 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).", - "Example": "```rust\nlet x = 3.14;\n```", - "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV." - }, - "group": "correctness", - "id": "approx_constant", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", - "Why is this bad": "Negations reduce the readability of statements.", - "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "if_not_else", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", - "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", - "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```", - "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure." - }, - "group": "pedantic", - "id": "filter_map", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for missing parameters in `panic!`.", - "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", - "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```", - "Known problems": "None." - }, - "group": "style", - "id": "panic_params", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", - "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", - "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```", - "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger." - }, - "group": "correctness", - "id": "while_immutable_condition", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", - "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", - "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```", - "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead." - }, - "group": "correctness", - "id": "absurd_extreme_comparisons", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", - "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", - "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "cast_ptr_alignment", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for formatting of `else if`. It lints if the `else`\nand `if` are not on the same line or the `else` seems to be missing.", - "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", - "Example": "```rust,ignore\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "suspicious_else_formatting", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for casts of a function pointer to a numeric type except `usize`.", - "Why is this bad": "Casting a function pointer to something other than `usize` is not a good style.", - "Example": "```rust\nfn test_fn() -> i16;\nlet _ = test_fn as i128\n```", - "Known problems": "None." - }, - "group": "style", - "id": "fn_to_numeric_cast", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", - "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", - "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```", - "Known problems": "None." - }, - "group": "style", - "id": "unsafe_removed_from_name", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", - "Why is this bad": "Redundant code.", - "Example": "```rust\nif x { false } else { true }\n```", - "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code." - }, - "group": "complexity", - "id": "needless_bool", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", - "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", - "Example": "```rust\n{ let x = ..; x }\n```", - "Known problems": "None." - }, - "group": "style", - "id": "let_and_return", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for return statements at the end of a block.", - "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", - "Example": "```rust\nfn foo(x: usize) { return x; }\n```", - "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker." - }, - "group": "style", - "id": "needless_return", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", - "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", - "Example": "```rust\nif x.len() == 0 { .. }\n```", - "Known problems": "None." - }, - "group": "style", - "id": "len_zero", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", - "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", - "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```", - "Known problems": "None." - }, - "group": "style", - "id": "suspicious_assignment_formatting", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", - "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", - "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```", - "Known problems": "Someone might actually mean `a op= a op b`, but that\nshould rather be written as `a = (2 * a) op b` where applicable." - }, - "group": "complexity", - "id": "misrefactored_assign_op", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", - "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", - "Example": "```rust\nlet bar: u8 = 123;\n\nstruct Foo {\n bar: u8,\n}\n\nlet foo = Foo{ bar: bar }\n```", - "Known problems": "None." - }, - "group": "style", - "id": "redundant_field_names", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", - "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", - "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```", - "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement." - }, - "group": "pedantic", - "id": "inline_always", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", - "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", - "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "forget_copy", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for names that are very similar and thus confusing.", - "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", - "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```", - "Known problems": "None?" - }, - "group": "pedantic", - "id": "similar_names", - "level": "Allow" - }, - { - "docs": { - "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", - "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", - "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```", - "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`." - }, - "group": "style", - "id": "write_literal", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for empty `loop` expressions.", - "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", - "Example": "```rust\nloop {}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "empty_loop", - "level": "Warn" - }, - { - "docs": { - "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", - "Why is this bad": "It's more concise and clear to just use the proper\nutility function", - "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\n```\n", - "Known problems": "None." - }, - "group": "style", - "id": "if_let_redundant_pattern_matching", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for the usage of negated comparision operators on types which only implement\n`PartialOrd` (e.g. `f64`).", - "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a forth one (Uncomparable). Escpeccially if\nthe operator based comparision result is negated it is easy to miss that fact.", - "Example": "```rust\nuse core::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "neg_cmp_op_on_partial_ord", - "level": "Warn" - }, - { - "docs": { - "What it does": "Warns if an integral constant literal starts with `0`.", - "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", - "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`).", - "Known problems": "None." - }, - "group": "complexity", - "id": "zero_prefixed_literal", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", - "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", - "Example": "```rust\nfor x..(y+1) { .. }\n```", - "Known problems": "None." - }, - "group": "nursery", - "id": "range_plus_one", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", - "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", - "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", - "Known problems": "None." - }, - "group": "nursery", - "id": "needless_borrow", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for expressions of the form `x == true` (or vice\nversa) and suggest using the variable directly.", - "Why is this bad": "Unnecessary code.", - "Example": "```rust\nif x == true { } // could be `if x { }`\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "bool_comparison", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for consecutive `if`s with the same condition.", - "Why is this bad": "This is probably a copy & paste error.", - "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```", - "Known problems": "Hopefully none." - }, - "group": "correctness", - "id": "ifs_same_cond", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", - "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", - "Example": "```rust\nfn as_u64(x: u8) -> u64 { x as u64 }\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 { u64::from(x) }\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "cast_lossless", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", - "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", - "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```", - "Known Problems": "None." - }, - "group": "style", - "id": "string_lit_as_bytes", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", - "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", - "Example": "```rust\nfn unused_lifetime<'a>(x: u8) { .. }\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "extra_unused_lifetimes", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", - "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", - "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `).", - "Example": "```rust\nx & 0x1111 == 0\n```", - "Known problems": "llvm generates better code for `x & 15 == 0` on x86" - }, - "group": "style", - "id": "verbose_bit_mask", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", - "Why is this bad": "Using `if let` or `match` is more idiomatic.", - "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```", - "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?" - }, - "group": "nursery", - "id": "unnecessary_unwrap", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for mapping `clone()` over an iterator.", - "Why is this bad": "It makes the code less readable than using the\n`.cloned()` adapter.", - "Example": "```rust\nx.map(|e| e.clone());\n```", - "Known problems": "Sometimes `.cloned()` requires stricter trait\nbound than `.map(|e| e.clone())` (which works because of the coercion).\nSee [#498](https://github.com/rust-lang-nursery/rust-clippy/issues/498)." - }, - "group": "style", - "id": "map_clone", - "level": "Warn" - }, - { - "docs": { - "What it does": "Nothing. This lint has been deprecated.", + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) { .. }\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE == 1.00f64\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type except `usize`.", + "Why is this bad": "Casting a function pointer to something other than `usize` is not a good style.", + "Known problems": "None.", + "Example": "```rust\nfn test_fn() -> i16;\nlet _ = test_fn as i128\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not enough to store address.", + "Why is this bad": "Casting a function pointer to not eligible type could truncate the address value.", + "Known problems": "None.", + "Example": "```rust\nfn test_fn() -> i16;\nlet _ = test_fn as i32\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```rust\nfor (k, _) in &map { .. }\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() { .. }\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in option { .. }\n```\n\nThis should be\n```rust\nif let Some(x) = option { .. }\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in result { .. }\n```\n\nThis should be\n```rust\nif let Ok(x) = result { .. }\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g. `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\n```" + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\n618_64_9189_73_511\n```" + } + }, + { + "id": "indexing_slicing", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang-nursery/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```rust\nfor x in y.next() { .. }\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```rust\nfor x in (5..5).step_by(0) { .. }\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\n6186491_8973511\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a emum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize { .. }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```rust\nif x.len() == 0 { .. }\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\n{ let x = ..; x }\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = { 1; };\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for mapping `clone()` over an iterator.", + "Why is this bad": "It makes the code less readable than using the\n`.cloned()` adapter.", + "Known problems": "Sometimes `.cloned()` requires stricter trait\nbound than `.map(|e| e.clone())` (which works because of the coercion).\nSee [#498](https://github.com/rust-lang-nursery/rust-clippy/issues/498).", + "Example": "```rust\nx.map(|e| e.clone());\n```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) { m.insert(k.clone(), v); }\n```", + "Example": "```rust\nif !m.contains_key(&k) { m.insert(k, v) }\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1 ... 10 => println!(\"1 ... 10\"),\n 5 ... 15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang-nursery/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x : Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55)))\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." - }, - "group": "deprecated", - "id": "misaligned_transmute", - "level": "Deprecated" - }, - { - "docs": { - "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", - "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", - "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "cast_possible_wrap", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for out of bounds array indexing with a constant\nindex.", - "Why is this bad": "This will always panic at runtime.", - "Example": "```rust\nlet x = [1,2,3,4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```", - "Known problems": "Hopefully none." - }, - "group": "correctness", - "id": "out_of_bounds_indexing", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", - "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", - "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "forget_ref", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", - "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", - "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```", - "Known problems": "The order of the arguments is not in execution order" - }, - "group": "pedantic", - "id": "option_map_unwrap_or", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for usage of `_.filter(_).next()`.", - "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", - "Example": "```rust\niter.filter(|x| x == 0).next()\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "filter_next", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", - "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", - "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 { x }\n```", - "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned." - }, - "group": "complexity", - "id": "needless_lifetimes", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).", - "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", - "Example": "```rust,ignore\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`.", - "Known problems": "Hopefully none." - }, - "group": "style", - "id": "new_without_default", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for `.unwrap()` calls on `Result`s.", - "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", - "Example": "```rust\nx.unwrap()\n```", - "Known problems": "None." - }, - "group": "restriction", - "id": "result_unwrap_used", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", - "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", - "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```", - "Known problems": "None." - }, - "group": "perf", - "id": "unused_collect", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", - "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", - "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X { .. }\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "should_implement_trait", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", - "Why is this bad": "Gankro says:\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`.", - "Example": "```rust\nlet x = LinkedList::new();\n```", - "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen." - }, - "group": "pedantic", - "id": "linkedlist", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for instances of `mut mut` references.", - "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", - "Example": "```rust\nlet x = &mut &mut y;\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "mut_mut", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", - "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", - "Example": "```rust\nlet x : Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "match_wild_err_arm", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for manual swapping.", - "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", - "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "manual_swap", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for getting the remainder of a division by one.", - "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", - "Example": "```rust\nx % 1\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "modulo_one", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", - "Why is this bad": "`.to_vec()` is clearer", - "Example": "```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s.to_vec();\n```", - "Known problems": "None." - }, - "group": "style", - "id": "iter_cloned_collect", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", - "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", - "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`.", - "Known problems": "None." - }, - "group": "pedantic", - "id": "unicode_not_nfc", - "level": "Allow" - }, - { - "docs": { - "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", - "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", - "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "suspicious_op_assign_impl", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", - "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", - "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "duration_subsec", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", - "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", - "Example": "```rust\nfor x in 5..10-5 { .. } // oops, stray `-`\n```", - "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone." - }, - "group": "correctness", - "id": "reverse_range_loop", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for modules that have the same name as their\nparent module", - "Why is this bad": "A 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.", - "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "module_inception", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for casts to the same type.", - "Why is this bad": "It's just unnecessary.", - "Example": "```rust\nlet _ = 2i32 as i32\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "unnecessary_cast", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for unused labels.", - "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", - "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```", - "Known problems": "Hopefully none." - }, - "group": "complexity", - "id": "unused_label", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", - "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", - "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "result_map_unit_fn", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for too many variables whose name consists of a\nsingle character.", - "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", - "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `).", - "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", - "Known problems": "None?" - }, - "group": "style", - "id": "many_single_char_names", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for `use Enum::*`.", - "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", - "Example": "```rust\nuse std::cmp::Ordering::*;\n```", - "Known problems": "Old-style enumerations that prefix the variants are\nstill around." - }, - "group": "pedantic", - "id": "enum_glob_use", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", - "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", - "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```", - "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon)." - }, - "group": "correctness", - "id": "ineffective_bit_mask", - "level": "Deny" - }, - { - "docs": { - "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", - "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", - "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```", - "Known problems": "None." - }, - "group": "style", - "id": "write_with_newline", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of `.clone()` on a `Copy` type.", - "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", - "Example": "```rust\n42u64.clone()\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "clone_on_copy", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for passing a unit value as an argument to a function without using a unit literal (`()`).", - "Why is this bad": "This is likely the result of an accidental semicolon.", - "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "unit_arg", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", - "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", - "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```", - "Known problems": "None?" - }, - "group": "style", - "id": "just_underscores_and_digits", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for use of `.skip(x).next()` on iterators.", - "Why is this bad": "`.nth(x)` is cleaner", - "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```", - "Known problems": "None." - }, - "group": "style", - "id": "iter_skip_next", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for double comparions that could be simpified to a single expression.", - "Why is this bad": "Readability.", - "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "double_comparisons", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", - "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", - "Example": "```rust\nlet mut x = 0;\nlet a = {x = 1; 1} + x;\n// Unclear whether a is 1 or 2.\n```", - "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order." - }, - "group": "complexity", - "id": "eval_order_dependence", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", - "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", - "Example": "```rust\nlet x = u64::MAX; x as f64\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "cast_precision_loss", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for references in expressions that use\nauto dereference.", - "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make sense.\nIt allows the crate to require all exported methods to be `#[inline]` by default, and then opt\nout for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nx % 1\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::atomic::AtomicBool` and `std::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::atomic::usize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x { false } else { true }\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "This will cause false positives in code generated by `derive`.\nFor instance in the following snippet:\n```rust\n#[derive(Debug)]\npub enum Error {\n Type(\n &'static str,\n ),\n}\n```\nA warning will be emitted that `&'static str` should be replaced with `&'static str`,\nhowever there is nothing that can or should be done to fix this." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\n let mut v = Vec::::new();\n let _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 { x }\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) { return x; }\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint { x: 1, y: 0, ..zero_point }\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g. `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```rust\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop { ..; break; }\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "new_without_default_derive", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method\nand no implementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html),\nwhere the `Default` can be derived by `#[derive(Default)]`.", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nJust prepend `#[derive(Default)]` before the `struct` definition." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) { println!(\"{}\", unsafe { *x }); }\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```rust\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet x = [1,2,3,4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```rust\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator", + "Why is this bad": "Question mark usage is more idiomatic", + "Known problems": "None", + "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee https://github.com/rust-lang-nursery/rust-clippy/issues/1439 for more\ndetails.", + "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```rust\nlet bar: u8 = 123;\n\nstruct Foo {\n bar: u8,\n}\n\nlet foo = Foo{ bar: bar }\n```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" - }, - "group": "complexity", - "id": "ref_in_deref", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", - "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", - "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "int_plus_one", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for large size differences between variants on\n`enum`s.", - "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", - "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a emum's variant to avoid box suggestion (defaults to `200 `).", - "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", - "Known problems": "None." - }, - "group": "perf", - "id": "large_enum_variant", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", - "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", - "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "drop_copy", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for binding a unit value.", - "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", - "Example": "```rust\nlet x = { 1; };\n```", - "Known problems": "None." - }, - "group": "style", - "id": "let_unit_value", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", - "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", - "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```", - "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used." - }, - "group": "style", - "id": "needless_pass_by_value", - "level": "Warn" - }, - { - "docs": { - "What it does": "Nothing. This lint has been deprecated.", + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```rust\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```rust\nfor x in 5..10-5 { .. } // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y; let x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend \nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X { .. }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => ()\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." - }, - "group": "deprecated", - "id": "str_to_string", - "level": "Deprecated" - }, - { - "docs": { - "What it does": "Checks for unnecessary double parentheses.", - "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", - "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "double_parens", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", - "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", - "Example": "```rust\nRegex::new(\"^foobar\")\n```", - "Known problems": "None." - }, - "group": "style", - "id": "trivial_regex", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", - "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", - "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "needless_range_loop", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for loops which have a range bound that is a mutable variable", - "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", - "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```", - "Known problems": "None" - }, - "group": "complexity", - "id": "mut_range_bound", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for functions with too many parameters.", - "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", - "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `).", - "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b:\nf32) { .. }\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "too_many_arguments", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for transmutes from an integer to a `bool`.", - "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", - "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n// should be:\nlet _: bool = x != 0;\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "transmute_int_to_bool", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for unused written/read amount.", - "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", - "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```", - "Known problems": "Detects only common patterns." - }, - "group": "correctness", - "id": "unused_io_amount", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for patterns in the form `name @ _`.", - "Why is this bad": "It's almost always more readable to just use direct\nbindings.", - "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```", - "Known problems": "None." - }, - "group": "style", - "id": "redundant_pattern", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for statements which have no effect.", - "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", - "Example": "```rust\n0;\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "no_effect", - "level": "Warn" - }, - { - "docs": { - "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", - "Why is this bad": "It requires the user to type the module name twice.", - "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "stutter", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", - "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", - "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```", - "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway." - }, - "group": "perf", - "id": "or_fun_call", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for non-ASCII characters in string literals.", - "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", - "Example": "```rust\nlet x = \"H\u00e4?\"\n```", - "Known problems": "None." - }, - "group": "pedantic", - "id": "non_ascii_literal", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", - "Why is this bad": "Using `(e)println! is clearer and more concise", - "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "explicit_write", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for creation of references to zeroed or uninitialized memory.", - "Why is this bad": "Creation of null references is undefined behavior.", - "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "invalid_ref", - "level": "Deny" - }, - { - "docs": { - "What it does": "Nothing. This lint has been deprecated.", - "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" - }, - "group": "deprecated", - "id": "range_step_by_zero", - "level": "Deprecated" - }, - { - "docs": { - "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", - "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", - "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```", - "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect." - }, - "group": "complexity", - "id": "deref_addrof", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for transmutes from an integer to a float.", - "Why is this bad": "This might result in an invalid in-memory representation of a float.", - "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n// should be:\nlet _: f32 = f32::from_bits(x);\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "transmute_int_to_float", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", - "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", - "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted.", - "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized." - }, - "group": "nursery", - "id": "panicking_unwrap", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for comparisons to unit.", - "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", - "Example": "```rust\nif { foo(); } == { bar(); } { baz(); }\n```\nis equal to\n```rust\n{ foo(); bar(); baz(); }\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "unit_cmp", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", - "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", - "Example": "```rust\nif { true } ..\n```", - "Known problems": "None." - }, - "group": "style", - "id": "block_in_if_condition_expr", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for `for` loops over `Result` values.", - "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", - "Example": "```rust\nfor x in result { .. }\n```\n\nThis should be\n```rust\nif let Ok(x) = result { .. }\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "for_loop_over_result", - "level": "Deny" - }, - { - "docs": { - "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", - "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", - "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```", - "Known problems": "None" - }, - "group": "pedantic", - "id": "needless_continue", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", - "Why is this bad": "This is probably a copy & paste error.", - "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```", - "Known problems": "Hopefully none." - }, - "group": "correctness", - "id": "if_same_then_else", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for use of `&Box` anywhere in the code.", - "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", - "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "borrowed_box", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for usage of `ok().expect(..)`.", - "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", - "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```", - "Known problems": "The error type needs to implement `Debug`" - }, - "group": "style", - "id": "ok_expect", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", - "Why is this bad": "Readability.", - "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() { .. }\n```", - "Known problems": "None" - }, - "group": "style", - "id": "explicit_into_iter_loop", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", - "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", - "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "match_as_ref", - "level": "Warn" - }, - { - "docs": { - "What it does": "Warns if there is a better representation for a numeric literal.", - "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", - "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `).", - "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", - "Known problems": "None." - }, - "group": "restriction", - "id": "decimal_literal_representation", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for iteration that is guaranteed to be infinite.", - "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", - "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "infinite_iter", - "level": "Deny" - }, - { - "docs": { - "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", - "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", - "Example": "```rust\nconst ONE == 1.00f64\nx == ONE // where both are floats\n```", - "Known problems": "None." - }, - "group": "restriction", - "id": "float_cmp_const", - "level": "Allow" - }, - { - "docs": { - "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", - "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", - "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```", - "Known problems": "None." - }, - "group": "complexity", - "id": "char_lit_as_u8", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", - "Why is this bad": "The function will always be called.", - "Example": "```rust\nfoo.expect(&format(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.unwrap_or_else(|_| panic!(format(\"Err {}: {}\", err_code, err_msg).as_str()))\n```", - "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway." - }, - "group": "perf", - "id": "expect_fun_call", - "level": "Warn" - }, - { - "docs": { - "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", - "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", - "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0\n}\n```", - "Known problems": "None." - }, - "group": "correctness", - "id": "enum_clike_unportable_variant", - "level": "Deny" - }, + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable. Also creates a new heap allocation and throws\naway the old one.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "stutter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else if`. It lints if the `else`\nand `if` are not on the same line or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\ncall_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b:\nf32) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool { .. }\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "This might result in an invalid in-memory representation of a float.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo { inner: Rc>>> }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```rust\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a unit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif { foo(); } == { bar(); } { baz(); }\n```\nis equal to\n```rust\n{ foo(); bar(); baz(); }\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```rust\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\n61864918973511\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", "docs": { - "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", - "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", - "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```", - "Known problems": "None." - }, - "group": "nursery", - "id": "fallible_impl_from", - "level": "Allow" + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {}\nimpl Foo {\n fn new() -> Foo {\n Foo {}\n }\n}\n```\ncould be\n```\nstruct Foo {}\nimpl Foo {\n fn new() -> Self {\n Self {}\n }\n}\n```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"too\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nx & 0x1111 == 0\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```rust\nwhile let Some(val) = iter() { .. }\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(\"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\n0 as *const u32\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } } ] \ No newline at end of file diff --git a/rust-1.29.1/index.html b/rust-1.29.1/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.29.1/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.29.1/lints.json b/rust-1.29.1/lints.json new file mode 100644 index 000000000000..e5e519579e02 --- /dev/null +++ b/rust-1.29.1/lints.json @@ -0,0 +1,3085 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust,ignore\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for compound assignment operations (`+=` and\nsimilar).", + "Why is this bad": "Projects with many developers from languages without\nthose operations may find them unreadable and not worth their weight.", + "Known problems": "Types implementing `OpAssign` don't necessarily\nimplement `Op`.", + "Example": "```rust\na += 1;\n```" + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } ..\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true` (or vice\nversa) and suggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true { } // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 { x as u64 }\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 { u64::from(x) }\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 { x as u8 }\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX; x as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\",*y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", + "Why is this bad": ": Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\nx == NAN\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```rust\nif x == ptr::null { .. }\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```rust\nconst 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```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n// `*t` or `&t`'s\n```" + } + }, + { + "id": "cyclomatic_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cyclomatic complexity.", + "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simpified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```rust\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nx + 1 == x + 1\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g. `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\n0 / x; 0 * x; x & 0\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {x = 1; 1} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n let v: f32 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789\n\n// Good\n let v: f64 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.unwrap_or_else(|_| panic!(format(\"Err {}: {}\", err_code, err_msg).as_str()))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() { .. }\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() { .. }\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) { .. }\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE == 1.00f64\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type except `usize`.", + "Why is this bad": "Casting a function pointer to something other than `usize` is not a good style.", + "Known problems": "None.", + "Example": "```rust\nfn test_fn() -> i16;\nlet _ = test_fn as i128\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not enough to store address.", + "Why is this bad": "Casting a function pointer to not eligible type could truncate the address value.", + "Known problems": "None.", + "Example": "```rust\nfn test_fn() -> i16;\nlet _ = test_fn as i32\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```rust\nfor (k, _) in &map { .. }\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() { .. }\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in option { .. }\n```\n\nThis should be\n```rust\nif let Some(x) = option { .. }\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in result { .. }\n```\n\nThis should be\n```rust\nif let Ok(x) = result { .. }\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g. `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\n```" + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\n618_64_9189_73_511\n```" + } + }, + { + "id": "indexing_slicing", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang-nursery/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```rust\nfor x in y.next() { .. }\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```rust\nfor x in (5..5).step_by(0) { .. }\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\n6186491_8973511\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a emum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize { .. }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```rust\nif x.len() == 0 { .. }\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\n{ let x = ..; x }\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = { 1; };\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for mapping `clone()` over an iterator.", + "Why is this bad": "It makes the code less readable than using the\n`.cloned()` adapter.", + "Known problems": "Sometimes `.cloned()` requires stricter trait\nbound than `.map(|e| e.clone())` (which works because of the coercion).\nSee [#498](https://github.com/rust-lang-nursery/rust-clippy/issues/498).", + "Example": "```rust\nx.map(|e| e.clone());\n```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) { m.insert(k.clone(), v); }\n```", + "Example": "```rust\nif !m.contains_key(&k) { m.insert(k, v) }\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1 ... 10 => println!(\"1 ... 10\"),\n 5 ... 15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang-nursery/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x : Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55)))\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make sense.\nIt allows the crate to require all exported methods to be `#[inline]` by default, and then opt\nout for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nx % 1\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::atomic::AtomicBool` and `std::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::atomic::usize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x { false } else { true }\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "This will cause false positives in code generated by `derive`.\nFor instance in the following snippet:\n```rust\n#[derive(Debug)]\npub enum Error {\n Type(\n &'static str,\n ),\n}\n```\nA warning will be emitted that `&'static str` should be replaced with `&'static str`,\nhowever there is nothing that can or should be done to fix this." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\n let mut v = Vec::::new();\n let _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 { x }\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) { return x; }\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint { x: 1, y: 0, ..zero_point }\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g. `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```rust\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop { ..; break; }\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "new_without_default_derive", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method\nand no implementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html),\nwhere the `Default` can be derived by `#[derive(Default)]`.", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nJust prepend `#[derive(Default)]` before the `struct` definition." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) { println!(\"{}\", unsafe { *x }); }\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```rust\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet x = [1,2,3,4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```rust\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator", + "Why is this bad": "Question mark usage is more idiomatic", + "Known problems": "None", + "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee https://github.com/rust-lang-nursery/rust-clippy/issues/1439 for more\ndetails.", + "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```rust\nlet bar: u8 = 123;\n\nstruct Foo {\n bar: u8,\n}\n\nlet foo = Foo{ bar: bar }\n```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```rust\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```rust\nfor x in 5..10-5 { .. } // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y; let x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend \nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X { .. }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => ()\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable. Also creates a new heap allocation and throws\naway the old one.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "stutter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else if`. It lints if the `else`\nand `if` are not on the same line or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\ncall_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b:\nf32) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool { .. }\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "This might result in an invalid in-memory representation of a float.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo { inner: Rc>>> }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```rust\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a unit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif { foo(); } == { bar(); } { baz(); }\n```\nis equal to\n```rust\n{ foo(); bar(); baz(); }\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```rust\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\n61864918973511\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {}\nimpl Foo {\n fn new() -> Foo {\n Foo {}\n }\n}\n```\ncould be\n```\nstruct Foo {}\nimpl Foo {\n fn new() -> Self {\n Self {}\n }\n}\n```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"too\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nx & 0x1111 == 0\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```rust\nwhile let Some(val) = iter() { .. }\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(\"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\n0 as *const u32\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.29.2/index.html b/rust-1.29.2/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.29.2/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.29.2/lints.json b/rust-1.29.2/lints.json new file mode 100644 index 000000000000..e5e519579e02 --- /dev/null +++ b/rust-1.29.2/lints.json @@ -0,0 +1,3085 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust,ignore\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for compound assignment operations (`+=` and\nsimilar).", + "Why is this bad": "Projects with many developers from languages without\nthose operations may find them unreadable and not worth their weight.", + "Known problems": "Types implementing `OpAssign` don't necessarily\nimplement `Op`.", + "Example": "```rust\na += 1;\n```" + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } ..\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true` (or vice\nversa) and suggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true { } // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 { x as u64 }\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 { u64::from(x) }\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 { x as u8 }\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX; x as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\",*y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", + "Why is this bad": ": Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\nx == NAN\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```rust\nif x == ptr::null { .. }\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```rust\nconst 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```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n// `*t` or `&t`'s\n```" + } + }, + { + "id": "cyclomatic_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cyclomatic complexity.", + "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simpified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```rust\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nx + 1 == x + 1\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g. `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\n0 / x; 0 * x; x & 0\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {x = 1; 1} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n let v: f32 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789\n\n// Good\n let v: f64 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.unwrap_or_else(|_| panic!(format(\"Err {}: {}\", err_code, err_msg).as_str()))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() { .. }\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() { .. }\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) { .. }\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE == 1.00f64\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type except `usize`.", + "Why is this bad": "Casting a function pointer to something other than `usize` is not a good style.", + "Known problems": "None.", + "Example": "```rust\nfn test_fn() -> i16;\nlet _ = test_fn as i128\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not enough to store address.", + "Why is this bad": "Casting a function pointer to not eligible type could truncate the address value.", + "Known problems": "None.", + "Example": "```rust\nfn test_fn() -> i16;\nlet _ = test_fn as i32\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```rust\nfor (k, _) in &map { .. }\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() { .. }\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in option { .. }\n```\n\nThis should be\n```rust\nif let Some(x) = option { .. }\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in result { .. }\n```\n\nThis should be\n```rust\nif let Ok(x) = result { .. }\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g. `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\n```" + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\n618_64_9189_73_511\n```" + } + }, + { + "id": "indexing_slicing", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang-nursery/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```rust\nfor x in y.next() { .. }\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```rust\nfor x in (5..5).step_by(0) { .. }\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\n6186491_8973511\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a emum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize { .. }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```rust\nif x.len() == 0 { .. }\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\n{ let x = ..; x }\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = { 1; };\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for mapping `clone()` over an iterator.", + "Why is this bad": "It makes the code less readable than using the\n`.cloned()` adapter.", + "Known problems": "Sometimes `.cloned()` requires stricter trait\nbound than `.map(|e| e.clone())` (which works because of the coercion).\nSee [#498](https://github.com/rust-lang-nursery/rust-clippy/issues/498).", + "Example": "```rust\nx.map(|e| e.clone());\n```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) { m.insert(k.clone(), v); }\n```", + "Example": "```rust\nif !m.contains_key(&k) { m.insert(k, v) }\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1 ... 10 => println!(\"1 ... 10\"),\n 5 ... 15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang-nursery/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x : Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55)))\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make sense.\nIt allows the crate to require all exported methods to be `#[inline]` by default, and then opt\nout for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nx % 1\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::atomic::AtomicBool` and `std::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::atomic::usize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x { false } else { true }\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "This will cause false positives in code generated by `derive`.\nFor instance in the following snippet:\n```rust\n#[derive(Debug)]\npub enum Error {\n Type(\n &'static str,\n ),\n}\n```\nA warning will be emitted that `&'static str` should be replaced with `&'static str`,\nhowever there is nothing that can or should be done to fix this." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\n let mut v = Vec::::new();\n let _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 { x }\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) { return x; }\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint { x: 1, y: 0, ..zero_point }\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g. `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```rust\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop { ..; break; }\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "new_without_default_derive", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method\nand no implementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html),\nwhere the `Default` can be derived by `#[derive(Default)]`.", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nJust prepend `#[derive(Default)]` before the `struct` definition." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) { println!(\"{}\", unsafe { *x }); }\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```rust\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet x = [1,2,3,4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```rust\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator", + "Why is this bad": "Question mark usage is more idiomatic", + "Known problems": "None", + "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee https://github.com/rust-lang-nursery/rust-clippy/issues/1439 for more\ndetails.", + "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```rust\nlet bar: u8 = 123;\n\nstruct Foo {\n bar: u8,\n}\n\nlet foo = Foo{ bar: bar }\n```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```rust\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```rust\nfor x in 5..10-5 { .. } // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y; let x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend \nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X { .. }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => ()\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable. Also creates a new heap allocation and throws\naway the old one.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "stutter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else if`. It lints if the `else`\nand `if` are not on the same line or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\ncall_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b:\nf32) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool { .. }\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "This might result in an invalid in-memory representation of a float.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo { inner: Rc>>> }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```rust\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a unit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif { foo(); } == { bar(); } { baz(); }\n```\nis equal to\n```rust\n{ foo(); bar(); baz(); }\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```rust\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\n61864918973511\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {}\nimpl Foo {\n fn new() -> Foo {\n Foo {}\n }\n}\n```\ncould be\n```\nstruct Foo {}\nimpl Foo {\n fn new() -> Self {\n Self {}\n }\n}\n```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"too\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nx & 0x1111 == 0\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```rust\nwhile let Some(val) = iter() { .. }\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(\"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\n0 as *const u32\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.30.0/index.html b/rust-1.30.0/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.30.0/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.30.0/lints.json b/rust-1.30.0/lints.json new file mode 100644 index 000000000000..2210c03c2642 --- /dev/null +++ b/rust-1.30.0/lints.json @@ -0,0 +1,3127 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust,ignore\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint is too subjective, not having a good reason for being in clippy.\nAdditionally, compound assignment operators may be overloaded separately from their non-assigning\ncounterparts, so this lint may suggest a change in behavior or the code may not compile." + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } ..\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true` (or vice\nversa) and suggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true { } // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 { x as u64 }\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 { u64::from(x) }\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 { x as u8 }\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX; x as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\",*y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\nx == NAN\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```rust\nif x == ptr::null { .. }\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```rust\nconst 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```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n// `*t` or `&t`'s\n```" + } + }, + { + "id": "cyclomatic_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cyclomatic complexity.", + "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simpified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```rust\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nx + 1 == x + 1\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g. `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\n0 / x; 0 * x; x & 0\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {x = 1; 1} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n let v: f32 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789\n\n// Good\n let v: f64 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() { .. }\n```\ncan be rewritten to\n```rust\nfor x in y { .. }\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() { .. }\n```\ncan be rewritten to\n```rust\nfor x in &y { .. }\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) { .. }\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE == 1.00f64\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type except `usize`.", + "Why is this bad": "Casting a function pointer to something other than `usize` is not a good style.", + "Known problems": "None.", + "Example": "```rust\nfn test_fn() -> i16;\nlet _ = test_fn as i128\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not enough to store address.", + "Why is this bad": "Casting a function pointer to not eligible type could truncate the address value.", + "Known problems": "None.", + "Example": "```rust\nfn test_fn() -> i16;\nlet _ = test_fn as i32\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```rust\nfor (k, _) in &map { .. }\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() { .. }\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in option { .. }\n```\n\nThis should be\n```rust\nif let Some(x) = option { .. }\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in result { .. }\n```\n\nThis should be\n```rust\nif let Ok(x) = result { .. }\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g. `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\n```" + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\n618_64_9189_73_511\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang-nursery/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```rust\nfor x in y.next() { .. }\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```rust\nfor x in (5..5).step_by(0) { .. }\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\n6186491_8973511\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a emum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize { .. }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```rust\nif x.len() == 0 { .. }\nif y.len() != 0 { .. }\n```\ninstead use\n```rust\nif x.len().is_empty() { .. }\nif !y.len().is_empty() { .. }\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = { 1; };\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for mapping `clone()` over an iterator.", + "Why is this bad": "It makes the code less readable than using the\n`.cloned()` adapter.", + "Known problems": "Sometimes `.cloned()` requires stricter trait\nbound than `.map(|e| e.clone())` (which works because of the coercion).\nSee [#498](https://github.com/rust-lang-nursery/rust-clippy/issues/498).", + "Example": "```rust\nx.map(|e| e.clone());\n```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) { m.insert(k.clone(), v); }\n```", + "Example": "```rust\nif !m.contains_key(&k) { m.insert(k, v) }\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1 ... 10 => println!(\"1 ... 10\"),\n 5 ... 15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang-nursery/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x : Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55)))\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make sense.\nIt allows the crate to require all exported methods to be `#[inline]` by default, and then opt\nout for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nx % 1\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::atomic::AtomicBool` and `std::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::atomic::usize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x { false } else { true }\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "This will cause false positives in code generated by `derive`.\nFor instance in the following snippet:\n```rust\n#[derive(Debug)]\npub enum Error {\n Type(\n &'static str,\n ),\n}\n```\nA warning will be emitted that `&'static str` should be replaced with `&'static str`,\nhowever there is nothing that can or should be done to fix this." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\n let mut v = Vec::::new();\n let _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 { x }\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) { return x; }\n```\nsimplify to\n```rust\nfn foo(x: usize) { x }\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint { x: 1, y: 0, ..zero_point }\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g. `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```rust\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop { ..; break; }\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "new_without_default_derive", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method\nand no implementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html),\nwhere the `Default` can be derived by `#[derive(Default)]`.", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nJust prepend `#[derive(Default)]` before the `struct` definition." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) { println!(\"{}\", unsafe { *x }); }\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```rust\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet x = [1,2,3,4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```rust\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe { ptr.offset(offset as isize); }\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe { ptr.add(offset); }\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator", + "Why is this bad": "Question mark usage is more idiomatic", + "Known problems": "None", + "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e: `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee https://github.com/rust-lang-nursery/rust-clippy/issues/1439 for more\ndetails.", + "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```rust\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```rust\nfor x in 5..10-5 { .. } // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y; let x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend \nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X { .. }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => ()\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "stutter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else if`. It lints if the `else`\nand `if` are not on the same line or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b:\nf32) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool { .. }\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "This might result in an invalid in-memory representation of a float.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo { inner: Rc>>> }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```rust\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a unit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif { foo(); } == { bar(); } { baz(); }\n```\nis equal to\n```rust\n{ foo(); bar(); baz(); }\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```rust\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\n61864918973511\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {}\nimpl Foo {\n fn new() -> Foo {\n Foo {}\n }\n}\n```\ncould be\n```\nstruct Foo {}\nimpl Foo {\n fn new() -> Self {\n Self {}\n }\n}\n```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"too\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nx & 0x1111 == 0\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```rust\nwhile let Some(val) = iter() { .. }\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(\"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\n0 as *const u32\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.30.1/index.html b/rust-1.30.1/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.30.1/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.30.1/lints.json b/rust-1.30.1/lints.json new file mode 100644 index 000000000000..2210c03c2642 --- /dev/null +++ b/rust-1.30.1/lints.json @@ -0,0 +1,3127 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust,ignore\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint is too subjective, not having a good reason for being in clippy.\nAdditionally, compound assignment operators may be overloaded separately from their non-assigning\ncounterparts, so this lint may suggest a change in behavior or the code may not compile." + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } ..\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true` (or vice\nversa) and suggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true { } // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 { x as u64 }\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 { u64::from(x) }\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 { x as u8 }\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX; x as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\",*y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\nx == NAN\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```rust\nif x == ptr::null { .. }\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```rust\nconst 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```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n// `*t` or `&t`'s\n```" + } + }, + { + "id": "cyclomatic_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cyclomatic complexity.", + "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simpified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```rust\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nx + 1 == x + 1\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g. `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\n0 / x; 0 * x; x & 0\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {x = 1; 1} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n let v: f32 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789\n\n// Good\n let v: f64 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() { .. }\n```\ncan be rewritten to\n```rust\nfor x in y { .. }\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() { .. }\n```\ncan be rewritten to\n```rust\nfor x in &y { .. }\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) { .. }\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE == 1.00f64\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type except `usize`.", + "Why is this bad": "Casting a function pointer to something other than `usize` is not a good style.", + "Known problems": "None.", + "Example": "```rust\nfn test_fn() -> i16;\nlet _ = test_fn as i128\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not enough to store address.", + "Why is this bad": "Casting a function pointer to not eligible type could truncate the address value.", + "Known problems": "None.", + "Example": "```rust\nfn test_fn() -> i16;\nlet _ = test_fn as i32\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```rust\nfor (k, _) in &map { .. }\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() { .. }\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in option { .. }\n```\n\nThis should be\n```rust\nif let Some(x) = option { .. }\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in result { .. }\n```\n\nThis should be\n```rust\nif let Ok(x) = result { .. }\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g. `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\n```" + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\n618_64_9189_73_511\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang-nursery/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```rust\nfor x in y.next() { .. }\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```rust\nfor x in (5..5).step_by(0) { .. }\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\n6186491_8973511\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a emum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize { .. }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```rust\nif x.len() == 0 { .. }\nif y.len() != 0 { .. }\n```\ninstead use\n```rust\nif x.len().is_empty() { .. }\nif !y.len().is_empty() { .. }\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = { 1; };\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for mapping `clone()` over an iterator.", + "Why is this bad": "It makes the code less readable than using the\n`.cloned()` adapter.", + "Known problems": "Sometimes `.cloned()` requires stricter trait\nbound than `.map(|e| e.clone())` (which works because of the coercion).\nSee [#498](https://github.com/rust-lang-nursery/rust-clippy/issues/498).", + "Example": "```rust\nx.map(|e| e.clone());\n```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) { m.insert(k.clone(), v); }\n```", + "Example": "```rust\nif !m.contains_key(&k) { m.insert(k, v) }\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1 ... 10 => println!(\"1 ... 10\"),\n 5 ... 15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang-nursery/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x : Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55)))\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make sense.\nIt allows the crate to require all exported methods to be `#[inline]` by default, and then opt\nout for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nx % 1\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::atomic::AtomicBool` and `std::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::atomic::usize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x { false } else { true }\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "This will cause false positives in code generated by `derive`.\nFor instance in the following snippet:\n```rust\n#[derive(Debug)]\npub enum Error {\n Type(\n &'static str,\n ),\n}\n```\nA warning will be emitted that `&'static str` should be replaced with `&'static str`,\nhowever there is nothing that can or should be done to fix this." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\n let mut v = Vec::::new();\n let _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 { x }\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) { return x; }\n```\nsimplify to\n```rust\nfn foo(x: usize) { x }\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint { x: 1, y: 0, ..zero_point }\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g. `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```rust\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop { ..; break; }\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "new_without_default_derive", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method\nand no implementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html),\nwhere the `Default` can be derived by `#[derive(Default)]`.", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nJust prepend `#[derive(Default)]` before the `struct` definition." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) { println!(\"{}\", unsafe { *x }); }\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```rust\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet x = [1,2,3,4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```rust\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe { ptr.offset(offset as isize); }\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe { ptr.add(offset); }\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator", + "Why is this bad": "Question mark usage is more idiomatic", + "Known problems": "None", + "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e: `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee https://github.com/rust-lang-nursery/rust-clippy/issues/1439 for more\ndetails.", + "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```rust\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```rust\nfor x in 5..10-5 { .. } // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y; let x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend \nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X { .. }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => ()\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "stutter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else if`. It lints if the `else`\nand `if` are not on the same line or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b:\nf32) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool { .. }\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "This might result in an invalid in-memory representation of a float.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo { inner: Rc>>> }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```rust\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a unit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif { foo(); } == { bar(); } { baz(); }\n```\nis equal to\n```rust\n{ foo(); bar(); baz(); }\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```rust\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\n61864918973511\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {}\nimpl Foo {\n fn new() -> Foo {\n Foo {}\n }\n}\n```\ncould be\n```\nstruct Foo {}\nimpl Foo {\n fn new() -> Self {\n Self {}\n }\n}\n```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"too\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nx & 0x1111 == 0\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```rust\nwhile let Some(val) = iter() { .. }\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(\"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\n0 as *const u32\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.31.0/index.html b/rust-1.31.0/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.31.0/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.31.0/lints.json b/rust-1.31.0/lints.json new file mode 100644 index 000000000000..ed506ad42733 --- /dev/null +++ b/rust-1.31.0/lints.json @@ -0,0 +1,3178 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust,ignore\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint is too subjective, not having a good reason for being in clippy.\nAdditionally, compound assignment operators may be overloaded separately from their non-assigning\ncounterparts, so this lint may suggest a change in behavior or the code may not compile." + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } ..\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true` (or vice\nversa) and suggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true { } // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 { x as u64 }\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 { u64::from(x) }\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 { x as u8 }\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX; x as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\",*y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\nx == NAN\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```rust\nif x == ptr::null { .. }\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```rust\nconst 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```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n// `*t` or `&t`'s\n```" + } + }, + { + "id": "cyclomatic_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cyclomatic complexity.", + "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simpified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```rust\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nx + 1 == x + 1\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g. `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\n0 / x; 0 * x; x & 0\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {x = 1; 1} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n let v: f32 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789\n\n// Good\n let v: f64 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() { .. }\n```\ncan be rewritten to\n```rust\nfor x in y { .. }\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() { .. }\n```\ncan be rewritten to\n```rust\nfor x in &y { .. }\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) { .. }\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE == 1.00f64\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 {}\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 {}\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 { 1 };\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 { 1 };\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```rust\nfor (k, _) in &map { .. }\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() { .. }\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in option { .. }\n```\n\nThis should be\n```rust\nif let Some(x) = option { .. }\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in result { .. }\n```\n\nThis should be\n```rust\nif let Ok(x) = result { .. }\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g. `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "The original rule will only lint for `if let`. After\nmaking it support to lint `match`, naming as `if let` is not suitable for it.\nSo, this lint is deprecated." + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\n618_64_9189_73_511\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang-nursery/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```rust\nfor x in y.next() { .. }\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```rust\nfor x in (5..5).step_by(0) { .. }\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\n6186491_8973511\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a emum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize { .. }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```rust\nif x.len() == 0 { .. }\nif y.len() != 0 { .. }\n```\ninstead use\n```rust\nif x.len().is_empty() { .. }\nif !y.len().is_empty() { .. }\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = { 1; };\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) { m.insert(k.clone(), v); }\n```", + "Example": "```rust\nif !m.contains_key(&k) { m.insert(k, v) }\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\niter.map(|x| x.iter()).flatten()\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1 ... 10 => println!(\"1 ... 10\"),\n 5 ... 15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang-nursery/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x : Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make sense.\nIt allows the crate to require all exported methods to be `#[inline]` by default, and then opt\nout for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nx % 1\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::atomic::AtomicBool` and `std::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::atomic::usize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x { false } else { true }\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "This will cause false positives in code generated by `derive`.\nFor instance in the following snippet:\n```rust\n#[derive(Debug)]\npub enum Error {\n Type(\n &'static str,\n ),\n}\n```\nA warning will be emitted that `&'static str` should be replaced with `&'static str`,\nhowever there is nothing that can or should be done to fix this." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\n let mut v = Vec::::new();\n let _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 { x }\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) { return x; }\n```\nsimplify to\n```rust\nfn foo(x: usize) { x }\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint { x: 1, y: 0, ..zero_point }\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g. `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```rust\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop { ..; break; }\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "The lint fires when the return type is wrapping `Self`.\nExample: `fn new() -> Result {}`", + "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "new_without_default_derive", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method\nand no implementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html),\nwhere the `Default` can be derived by `#[derive(Default)]`.", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nJust prepend `#[derive(Default)]` before the `struct` definition." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) { println!(\"{}\", unsafe { *x }); }\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```rust\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet x = [1,2,3,4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```rust\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe { ptr.offset(offset as isize); }\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe { ptr.add(offset); }\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator", + "Why is this bad": "Question mark usage is more idiomatic", + "Known problems": "None", + "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e: `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee https://github.com/rust-lang-nursery/rust-clippy/issues/1439 for more\ndetails.", + "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```rust\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```rust\nfor x in 5..10-5 { .. } // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y; let x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend\nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X { .. }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => ()\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "stutter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else if`. It lints if the `else`\nand `if` are not on the same line or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b:\nf32) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool { .. }\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "This might result in an invalid in-memory representation of a float.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo { inner: Rc>>> }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```rust\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a unit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif { foo(); } == { bar(); } { baz(); }\n```\nis equal to\n```rust\n{ foo(); bar(); baz(); }\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```rust\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\n61864918973511\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g. the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () { () }\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {}\nimpl Foo {\n fn new() -> Foo {\n Foo {}\n }\n}\n```\ncould be\n```\nstruct Foo {}\nimpl Foo {\n fn new() -> Self {\n Self {}\n }\n}\n```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"too\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nx & 0x1111 == 0\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```rust\nwhile let Some(val) = iter() { .. }\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(\"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\n0 as *const u32\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.31.1/index.html b/rust-1.31.1/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.31.1/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.31.1/lints.json b/rust-1.31.1/lints.json new file mode 100644 index 000000000000..ed506ad42733 --- /dev/null +++ b/rust-1.31.1/lints.json @@ -0,0 +1,3178 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust,ignore\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint is too subjective, not having a good reason for being in clippy.\nAdditionally, compound assignment operators may be overloaded separately from their non-assigning\ncounterparts, so this lint may suggest a change in behavior or the code may not compile." + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } ..\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true` (or vice\nversa) and suggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true { } // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 { x as u64 }\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 { u64::from(x) }\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 { x as u8 }\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX; x as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\",*y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\nx == NAN\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```rust\nif x == ptr::null { .. }\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```rust\nconst 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```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n// `*t` or `&t`'s\n```" + } + }, + { + "id": "cyclomatic_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cyclomatic complexity.", + "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simpified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```rust\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nx + 1 == x + 1\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g. `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\n0 / x; 0 * x; x & 0\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {x = 1; 1} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n let v: f32 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789\n\n// Good\n let v: f64 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() { .. }\n```\ncan be rewritten to\n```rust\nfor x in y { .. }\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() { .. }\n```\ncan be rewritten to\n```rust\nfor x in &y { .. }\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) { .. }\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE == 1.00f64\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 {}\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 {}\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 { 1 };\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 { 1 };\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```rust\nfor (k, _) in &map { .. }\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() { .. }\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in option { .. }\n```\n\nThis should be\n```rust\nif let Some(x) = option { .. }\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in result { .. }\n```\n\nThis should be\n```rust\nif let Ok(x) = result { .. }\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g. `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "The original rule will only lint for `if let`. After\nmaking it support to lint `match`, naming as `if let` is not suitable for it.\nSo, this lint is deprecated." + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\n618_64_9189_73_511\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang-nursery/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```rust\nfor x in y.next() { .. }\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```rust\nfor x in (5..5).step_by(0) { .. }\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\n6186491_8973511\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a emum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize { .. }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```rust\nif x.len() == 0 { .. }\nif y.len() != 0 { .. }\n```\ninstead use\n```rust\nif x.len().is_empty() { .. }\nif !y.len().is_empty() { .. }\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = { 1; };\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) { m.insert(k.clone(), v); }\n```", + "Example": "```rust\nif !m.contains_key(&k) { m.insert(k, v) }\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\niter.map(|x| x.iter()).flatten()\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1 ... 10 => println!(\"1 ... 10\"),\n 5 ... 15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang-nursery/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x : Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make sense.\nIt allows the crate to require all exported methods to be `#[inline]` by default, and then opt\nout for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nx % 1\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::atomic::AtomicBool` and `std::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::atomic::usize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x { false } else { true }\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "This will cause false positives in code generated by `derive`.\nFor instance in the following snippet:\n```rust\n#[derive(Debug)]\npub enum Error {\n Type(\n &'static str,\n ),\n}\n```\nA warning will be emitted that `&'static str` should be replaced with `&'static str`,\nhowever there is nothing that can or should be done to fix this." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\n let mut v = Vec::::new();\n let _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 { x }\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) { return x; }\n```\nsimplify to\n```rust\nfn foo(x: usize) { x }\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint { x: 1, y: 0, ..zero_point }\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g. `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```rust\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop { ..; break; }\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "The lint fires when the return type is wrapping `Self`.\nExample: `fn new() -> Result {}`", + "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "new_without_default_derive", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method\nand no implementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html),\nwhere the `Default` can be derived by `#[derive(Default)]`.", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nJust prepend `#[derive(Default)]` before the `struct` definition." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) { println!(\"{}\", unsafe { *x }); }\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```rust\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet x = [1,2,3,4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```rust\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe { ptr.offset(offset as isize); }\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe { ptr.add(offset); }\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator", + "Why is this bad": "Question mark usage is more idiomatic", + "Known problems": "None", + "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e: `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee https://github.com/rust-lang-nursery/rust-clippy/issues/1439 for more\ndetails.", + "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```rust\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```rust\nfor x in 5..10-5 { .. } // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y; let x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend\nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X { .. }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => ()\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "stutter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else if`. It lints if the `else`\nand `if` are not on the same line or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b:\nf32) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool { .. }\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "This might result in an invalid in-memory representation of a float.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo { inner: Rc>>> }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```rust\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a unit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif { foo(); } == { bar(); } { baz(); }\n```\nis equal to\n```rust\n{ foo(); bar(); baz(); }\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```rust\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\n61864918973511\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g. the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () { () }\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {}\nimpl Foo {\n fn new() -> Foo {\n Foo {}\n }\n}\n```\ncould be\n```\nstruct Foo {}\nimpl Foo {\n fn new() -> Self {\n Self {}\n }\n}\n```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"too\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nx & 0x1111 == 0\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```rust\nwhile let Some(val) = iter() { .. }\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(\"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\n0 as *const u32\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.32.0/index.html b/rust-1.32.0/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.32.0/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.32.0/lints.json b/rust-1.32.0/lints.json new file mode 100644 index 000000000000..53b87733e239 --- /dev/null +++ b/rust-1.32.0/lints.json @@ -0,0 +1,3288 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust,ignore\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint is too subjective, not having a good reason for being in clippy.\nAdditionally, compound assignment operators may be overloaded separately from their non-assigning\ncounterparts, so this lint may suggest a change in behavior or the code may not compile." + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } ..\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true` (or vice\nversa) and suggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true { } // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cargo_common_metadata", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks 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", + "Why is this bad": "It will be more difficult for users to discover the\npurpose of the crate, and key information related to it.", + "Known problems": "None.", + "Example": "```toml\n# This `Cargo.toml` is missing an authors field:\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/Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 { x as u64 }\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 { u64::from(x) }\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 { x as u8 }\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX; x as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\",*y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\nx == NAN\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```rust\nif x == ptr::null { .. }\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```rust\nconst 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```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n// `*t` or `&t`'s\n```" + } + }, + { + "id": "cyclomatic_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cyclomatic complexity.", + "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{Ordering::SeqCst, AtomicUsize};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_cfg_attr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.", + "Why is this bad": "Since 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.", + "Known problems": "This 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)", + "Example": "Bad:\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nGood:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simpified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```rust\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nx + 1 == x + 1\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g. `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\n0 / x; 0 * x; x & 0\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {x = 1; 1} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n let v: f32 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789\n\n// Good\n let v: f64 = 0.123_456_789_9;\n println!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() { .. }\n```\ncan be rewritten to\n```rust\nfor x in y { .. }\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() { .. }\n```\ncan be rewritten to\n```rust\nfor x in &y { .. }\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) { .. }\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE == 1.00f64\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 {}\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 {}\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 { 1 };\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 { 1 };\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```rust\nfor (k, _) in &map { .. }\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() { .. }\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in option { .. }\n```\n\nThis should be\n```rust\nif let Some(x) = option { .. }\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in result { .. }\n```\n\nThis should be\n```rust\nif let Ok(x) = result { .. }\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x:i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n// original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "Not a replacement for error handling: Using either\n`.unwrap()` or the Index trait (`[]`) carries the risk of causing a `panic`\nif the value being accessed is `None`. If the use of `.get().unwrap()` is a\ntemporary placeholder for dealing with the `Option` type, then this does\nnot mitigate the need for error handling. If there is a chance that `.get()`\nwill be `None` in your program, then it is advisable that the `None` case\nis handled in a future refactor instead of using `.unwrap()` or the Index\ntrait.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g. `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "The original rule will only lint for `if let`. After\nmaking it support to lint `match`, naming as `if let` is not suitable for it.\nSo, this lint is deprecated." + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\n618_64_9189_73_511\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "into_iter_on_array", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `into_iter` calls on types which should be replaced by `iter` or\n`iter_mut`.", + "Why is this bad": "Arrays and `PathBuf` do not yet have an `into_iter` method which move out\ntheir content into an iterator. Auto-referencing resolves the `into_iter` call to its reference\ninstead, like `<&[T; N] as IntoIterator>::into_iter`, which just iterates over item references\nlike calling `iter` would. Furthermore, when the standard library actually\n[implements the `into_iter` method][25725] which moves the content out of the array, the\noriginal use of `into_iter` got inferred with the wrong type and the code will be broken.", + "Known problems": "None", + "Example": "```rust\nlet _ = [1, 2, 3].into_iter().map(|x| *x).collect::>();\n```\n\n[25725]: https://github.com/rust-lang/rust/issues/25725" + } + }, + { + "id": "into_iter_on_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `into_iter` calls on references which should be replaced by `iter`\nor `iter_mut`.", + "Why is this bad": "Readability. Calling `into_iter` on a reference will not move out its\ncontent into the resulting iterator, which is confusing. It is better just call `iter` or\n`iter_mut` directly.", + "Known problems": "None", + "Example": "```rust\nlet _ = (&vec![3, 4, 5]).into_iter();\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1,2,3,4,5];\nlet s2 : Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```rust\nfor x in y.next() { .. }\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```rust\nfor x in (5..5).step_by(0) { .. }\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\n6186491_8973511\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a emum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize { .. }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```rust\nif x.len() == 0 { .. }\nif y.len() != 0 { .. }\n```\ninstead use\n```rust\nif x.len().is_empty() { .. }\nif !y.len().is_empty() { .. }\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = { 1; };\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) { m.insert(k.clone(), v); }\n```", + "Example": "```rust\nif !m.contains_key(&k) { m.insert(k, v) }\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\niter.map(|x| x.iter()).flatten()\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1 ... 10 => println!(\"1 ... 10\"),\n 5 ... 15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x : Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_discriminant_non_enum", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `mem::discriminant()` on a non-enum type.", + "Why is this bad": "The value of `mem::discriminant()` on non-enum types\nis unspecified.", + "Known problems": "None.", + "Example": "```rust\nmem::discriminant(&\"hello\");\nmem::discriminant(&&Some(2));\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make sense.\nIt allows the crate to require all exported methods to be `#[inline]` by default, and then opt\nout for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nx % 1\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::atomic::AtomicBool` and `std::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::atomic::usize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x { false } else { true }\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "None." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\n let mut v = Vec::::new();\n let _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 { x }\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) { return x; }\n```\nsimplify to\n```rust\nfn foo(x: usize) { x }\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint { x: 1, y: 0, ..zero_point }\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g. `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```rust\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop { ..; break; }\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "new_without_default_derive", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method\nand no implementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html),\nwhere the `Default` can be derived by `#[derive(Default)]`.", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nJust prepend `#[derive(Default)]` before the `struct` definition." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) { println!(\"{}\", unsafe { *x }); }\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```rust\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet x = [1,2,3,4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```rust\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe { ptr.offset(offset as isize); }\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe { ptr.add(offset); }\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator", + "Why is this bad": "Question mark usage is more idiomatic", + "Known problems": "None", + "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e: `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_clone", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for a redudant `clone()` (and its relatives) which clones an owned\nvalue that is going to be dropped without further use.", + "Why is this bad": "It is not always possible for the compiler to eliminate useless\nallocations and deallocations generated by redundant `clone()`s.", + "Known problems": "* Suggestions made by this lint could require NLL to be enabled.\n* False-positive if there is a borrow preventing the value from moving out.\n\n```rust\nlet x = String::new();\n\nlet y = &x;\n\nfoo(x.clone()); // This lint suggests to remove this `clone()`\n```", + "Example": "```rust\n{\n let x = Foo::new();\n call(x.clone());\n call(x.clone()); // this can just pass `x`\n}\n\n[\"lorem\", \"ipsum\"].join(\" \").to_string()\n\nPath::new(\"/a/b\").join(\"c\").to_path_buf()\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee https://github.com/rust-lang/rust-clippy/issues/1439 for more\ndetails.", + "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```rust\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```rust\nfor x in 5..10-5 { .. } // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y; let x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend\nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X { .. }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => ()\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```" + } + }, + { + "id": "slow_vector_initialization", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks slow zero-filled vector initialization", + "Why is this bad": "This structures are non-idiomatic and less efficient than simply using\n`vec![len; 0]`.", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nvec1.resize(len, 0);\n\nlet mut vec2 = Vec::with_capacity(len);\nvec2.extend(repeat(0).take(len))\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "stutter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else if`. It lints if the `else`\nand `if` are not on the same line or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b:\nf32) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool { .. }\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "This might result in an invalid in-memory representation of a float.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo { inner: Rc>>> }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```rust\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a unit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif { foo(); } == { bar(); } { baz(); }\n```\nis equal to\n```rust\n{ foo(); bar(); baz(); }\n```" + } + }, + { + "id": "unknown_clippy_lints", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `allow`/`warn`/`deny`/`forbid` attributes with scoped clippy\nlints and if those lints exist in clippy. If there is a uppercase letter in the lint name\n(not the tool name) and a lowercase version of this lint exists, it will suggest to lowercase\nthe lint name.", + "Why is this bad": "A lint attribute with a mistyped lint name won't have an effect.", + "Known problems": "None.", + "Example": "Bad:\n```rust\n#![warn(if_not_els)]\n#![deny(clippy::All)]\n```\n\nGood:\n```rust\n#![warn(if_not_else)]\n#![deny(clippy::all)]\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```rust\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\n61864918973511\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unsafe_vector_initialization", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks unsafe vector initialization", + "Why is this bad": "Changing the length of a vector may expose uninitialized memory, which\ncan lead to memory safety issues", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nunsafe { vec1.set_len(len); }\n```" + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g. the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () { () }\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1,2,3,4,5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"foo\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nx & 0x1111 == 0\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```rust\nwhile let Some(val) = iter() { .. }\n```" + } + }, + { + "id": "wildcard_dependencies", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard dependencies in the `Cargo.toml`.", + "Why is this bad": "[As the edition guide says](https://rust-lang-nursery.github.io/edition-guide/rust-2018/cargo-and-crates-io/crates-io-disallows-wildcard-dependencies.html),\nit is highly unlikely that you work with any possible version of your dependency,\nand wildcard dependencies would cause unnecessary breakage in the ecosystem.", + "Known problems": "None.", + "Example": "```toml\n[dependencies]\nregex = \"*\"\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(\"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n fn as_str(self) -> &str { .. }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\n0 as *const u32\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.33.0/index.html b/rust-1.33.0/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.33.0/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.33.0/lints.json b/rust-1.33.0/lints.json new file mode 100644 index 000000000000..06775a339923 --- /dev/null +++ b/rust-1.33.0/lints.json @@ -0,0 +1,3308 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust,ignore\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint is too subjective, not having a good reason for being in clippy.\nAdditionally, compound assignment operators may be overloaded separately from their non-assigning\ncounterparts, so this lint may suggest a change in behavior or the code may not compile." + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } ..\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true`,\n`x != true` and order comparisons such as `x < true` (or vice versa) and\nsuggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true {} // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cargo_common_metadata", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks 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", + "Why is this bad": "It will be more difficult for users to discover the\npurpose of the crate, and key information related to it.", + "Known problems": "None.", + "Example": "```toml\n# This `Cargo.toml` is missing an authors field:\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/Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 {\n x as u64\n}\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 {\n u64::from(x)\n}\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 {\n x as u8\n}\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX;\nx as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_ref_to_mut", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of `&T` to `&mut T` anywhere in the code.", + "Why is this bad": "It\u2019s basically guaranteed to be undefined behaviour.\n`UnsafeCell` is the only way to obtain aliasable data that is considered\nmutable.", + "Known problems": "None.", + "Example": "```rust\nfn x(r: &i32) {\n unsafe {\n *(r as *const _ as *mut _) += 1;\n }\n}\n```\n\nInstead consider using interior mutability types.\n\n```rust\nfn x(r: &UnsafeCell) {\n unsafe {\n *r.get() += 1;\n }\n}\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\", *y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\nx == NAN\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```rust\nif x == ptr::null {\n ..\n}\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```rust\nconst 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```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n // `*t` or `&t`'s\n```" + } + }, + { + "id": "cyclomatic_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cyclomatic complexity.", + "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_cfg_attr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.", + "Why is this bad": "Since 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.", + "Known problems": "This 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)", + "Example": "Bad:\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nGood:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n \"CamelCase\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simplified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```rust\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0,\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nx + 1 == x + 1\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g. `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\n0 / x;\n0 * x;\nx & 0\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {\n x = 1;\n 1\n} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet v: f32 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789\n\n// Good\nlet v: f64 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() {\n ..\n}\n```\ncan be rewritten to\n```rust\nfor x in y {\n ..\n}\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() {\n ..\n}\n```\ncan be rewritten to\n```rust\nfor x in &y {\n ..\n}\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) {\n ..\n}\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE == 1.00f64\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 {}\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 {}\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 {\n 1\n};\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 {\n 1\n};\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```rust\nfor (k, _) in &map {\n ..\n}\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in option {\n ..\n}\n```\n\nThis should be\n```rust\nif let Some(x) = option {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in result {\n ..\n}\n```\n\nThis should be\n```rust\nif let Ok(x) = result {\n ..\n}\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "Not a replacement for error handling: Using either\n`.unwrap()` or the Index trait (`[]`) carries the risk of causing a `panic`\nif the value being accessed is `None`. If the use of `.get().unwrap()` is a\ntemporary placeholder for dealing with the `Option` type, then this does\nnot mitigate the need for error handling. If there is a chance that `.get()`\nwill be `None` in your program, then it is advisable that the `None` case\nis handled in a future refactor instead of using `.unwrap()` or the Index\ntrait.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g. `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "The original rule will only lint for `if let`. After\nmaking it support to lint `match`, naming as `if let` is not suitable for it.\nSo, this lint is deprecated." + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```" + } + }, + { + "id": "implicit_return", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for missing return statements at the end of a block.", + "Why is this bad": "Actually omitting the return keyword is idiomatic Rust code. Programmers\ncoming from other languages might prefer the expressiveness of `return`. It's possible to miss\nthe last returning statement because the only difference is a missing `;`. Especially in bigger\ncode with multiple return paths having a `return` keyword makes it easier to find the\ncorresponding statements.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: usize) {\n x\n}\n```\nadd return\n```rust\nfn foo(x: usize) {\n return x;\n}\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\n618_64_9189_73_511\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "into_iter_on_array", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `into_iter` calls on types which should be replaced by `iter` or\n`iter_mut`.", + "Why is this bad": "Arrays and `PathBuf` do not yet have an `into_iter` method which move out\ntheir content into an iterator. Auto-referencing resolves the `into_iter` call to its reference\ninstead, like `<&[T; N] as IntoIterator>::into_iter`, which just iterates over item references\nlike calling `iter` would. Furthermore, when the standard library actually\n[implements the `into_iter` method][25725] which moves the content out of the array, the\noriginal use of `into_iter` got inferred with the wrong type and the code will be broken.", + "Known problems": "None", + "Example": "```rust\nlet _ = [1, 2, 3].into_iter().map(|x| *x).collect::>();\n```\n\n[25725]: https://github.com/rust-lang/rust/issues/25725" + } + }, + { + "id": "into_iter_on_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `into_iter` calls on references which should be replaced by `iter`\nor `iter_mut`.", + "Why is this bad": "Readability. Calling `into_iter` on a reference will not move out its\ncontent into the resulting iterator, which is confusing. It is better just call `iter` or\n`iter_mut` directly.", + "Known problems": "None", + "Example": "```rust\nlet _ = (&vec![3, 4, 5]).into_iter();\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```rust\nfor x in y.next() {\n ..\n}\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```rust\nfor x in (5..5).step_by(0) {\n ..\n}\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\n6186491_8973511\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a enum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize {\n ..\n }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```rust\nif x.len() == 0 {\n ..\n}\nif y.len() != 0 {\n ..\n}\n```\ninstead use\n```rust\nif x.is_empty() {\n ..\n}\nif !y.is_empty() {\n ..\n}\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = {\n 1;\n};\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) {\n m.insert(k.clone(), v);\n}\n```", + "Example": "```rust\nif !m.contains_key(&k) {\n m.insert(k, v)\n}\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\niter.map(|x| x.iter()).flatten()\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1...10 => println!(\"1 ... 10\"),\n 5...15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x: Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_discriminant_non_enum", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `mem::discriminant()` on a non-enum type.", + "Why is this bad": "The value of `mem::discriminant()` on non-enum types\nis unspecified.", + "Known problems": "None.", + "Example": "```rust\nmem::discriminant(&\"hello\");\nmem::discriminant(&&Some(2));\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make\nsense. It allows the crate to require all exported methods to be `#[inline]` by default, and\nthen opt out for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "module_name_repetitions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nx % 1\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::sync::atomic::AtomicBool` and `std::sync::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::sync::atomic::AtomicUsize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x {\n false\n} else {\n true\n}\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "None." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\nlet mut v = Vec::::new();\nlet _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 {\n x\n}\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) {\n return x;\n}\n```\nsimplify to\n```rust\nfn foo(x: usize) {\n x\n}\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint {\n x: 1,\n y: 0,\n ..zero_point\n}\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g. `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```rust\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop {\n ..;\n break;\n}\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).\n\nIt detects both the case when a manual\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\nimplementation is required and also when it can be created with\n`#[derive(Default)]`", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nOr, if\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\ncan be derived by `#[derive(Default)]`:\n\n```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nInstead, use:\n\n```rust\n#[derive(Default)]\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) {\n println!(\"{}\", unsafe { *x });\n}\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```rust\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet x = [1, 2, 3, 4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```rust\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.offset(offset as isize);\n}\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.add(offset);\n}\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator", + "Why is this bad": "Question mark usage is more idiomatic", + "Known problems": "None", + "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e: `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_clone", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for a redudant `clone()` (and its relatives) which clones an owned\nvalue that is going to be dropped without further use.", + "Why is this bad": "It is not always possible for the compiler to eliminate useless\nallocations and deallocations generated by redundant `clone()`s.", + "Known problems": "* Suggestions made by this lint could require NLL to be enabled.\n* False-positive if there is a borrow preventing the value from moving out.\n\n```rust\nlet x = String::new();\n\nlet y = &x;\n\nfoo(x.clone()); // This lint suggests to remove this `clone()`\n```", + "Example": "```rust\n{\n let x = Foo::new();\n call(x.clone());\n call(x.clone()); // this can just pass `x`\n}\n\n[\"lorem\", \"ipsum\"].join(\" \").to_string()\n\nPath::new(\"/a/b\").join(\"c\").to_path_buf()\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee https://github.com/rust-lang/rust-clippy/issues/1439 for more\ndetails.", + "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```rust\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```rust\nfor x in 5..10 - 5 {\n ..\n} // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y;\nlet x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend\nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X {\n ..\n }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => (),\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let else` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "Using `match`:\n\n```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```\n\nUsing `if let` with `else`:\n\n```rust\nif let Some(ref foo) = x {\n bar(foo);\n} else {\n bar(other_ref);\n}\n```" + } + }, + { + "id": "slow_vector_initialization", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks slow zero-filled vector initialization", + "Why is this bad": "This structures are non-idiomatic and less efficient than simply using\n`vec![len; 0]`.", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nvec1.resize(len, 0);\n\nlet mut vec2 = Vec::with_capacity(len);\nvec2.extend(repeat(0).take(len))\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else`. It lints if the `else`\nis followed immediately by a newline or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} { // looks like an `else` is missing here\n}\n\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\n{ // this is the `else` block of the previous `if`, but should it be?\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n ..\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool {\n ..\n}\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "This might result in an invalid in-memory representation of a float.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```rust\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a\nunit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif {\n foo();\n} == {\n bar();\n} {\n baz();\n}\n```\nis equal to\n```rust\n{\n foo();\n bar();\n baz();\n}\n```" + } + }, + { + "id": "unknown_clippy_lints", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `allow`/`warn`/`deny`/`forbid` attributes with scoped clippy\nlints and if those lints exist in clippy. If there is a uppercase letter in the lint name\n(not the tool name) and a lowercase version of this lint exists, it will suggest to lowercase\nthe lint name.", + "Why is this bad": "A lint attribute with a mistyped lint name won't have an effect.", + "Known problems": "None.", + "Example": "Bad:\n```rust\n#![warn(if_not_els)]\n#![deny(clippy::All)]\n```\n\nGood:\n```rust\n#![warn(if_not_else)]\n#![deny(clippy::all)]\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```rust\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\n61864918973511\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unsafe_vector_initialization", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint used to suggest replacing `let mut vec =\nVec::with_capacity(n); vec.set_len(n);` with `let vec = vec![0; n];`. The\nreplacement has very different performance characteristics so the lint is\ndeprecated." + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g. the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () {\n ()\n}\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "- False positive when using associated types (#2843)\n- False positives in some situations when using generics (#3410)", + "Example": "```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```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"foo\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "vec_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Vec>` where T: Sized anywhere in the code.", + "Why is this bad": "`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.", + "Known problems": "Vec> makes sense if T is a large type (see #3530,\n1st comment).", + "Example": "```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nx & 0x1111 == 0\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```rust\nwhile let Some(val) = iter() {\n ..\n}\n```" + } + }, + { + "id": "wildcard_dependencies", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard dependencies in the `Cargo.toml`.", + "Why is this bad": "[As the edition guide says](https://rust-lang-nursery.github.io/edition-guide/rust-2018/cargo-and-crates-io/crates-io-disallows-wildcard-dependencies.html),\nit is highly unlikely that you work with any possible version of your dependency,\nand wildcard dependencies would cause unnecessary breakage in the ecosystem.", + "Known problems": "None.", + "Example": "```toml\n[dependencies]\nregex = \"*\"\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(\"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\n0 as *const u32\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.34.0/index.html b/rust-1.34.0/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.34.0/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.34.0/lints.json b/rust-1.34.0/lints.json new file mode 100644 index 000000000000..357685eec84c --- /dev/null +++ b/rust-1.34.0/lints.json @@ -0,0 +1,3364 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust,ignore\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assertions_on_constants", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Check to call assert!(true/false)", + "Why is this bad": "Will be optimized out by the compiler or should probably be replaced by a\npanic!() or unreachable!()", + "Known problems": "None", + "Example": "```rust\nassert!(false)\n// or\nassert!(true)\n// or\nconst B: bool = false;\nassert!(B)\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint is too subjective, not having a good reason for being in clippy.\nAdditionally, compound assignment operators may be overloaded separately from their non-assigning\ncounterparts, so this lint may suggest a change in behavior or the code may not compile." + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } ..\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true`,\n`x != true` and order comparisons such as `x < true` (or vice versa) and\nsuggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true {} // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cargo_common_metadata", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks 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", + "Why is this bad": "It will be more difficult for users to discover the\npurpose of the crate, and key information related to it.", + "Known problems": "None.", + "Example": "```toml\n# This `Cargo.toml` is missing an authors field:\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/Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 {\n x as u64\n}\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 {\n u64::from(x)\n}\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 {\n x as u8\n}\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX;\nx as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_ref_to_mut", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of `&T` to `&mut T` anywhere in the code.", + "Why is this bad": "It\u2019s basically guaranteed to be undefined behaviour.\n`UnsafeCell` is the only way to obtain aliasable data that is considered\nmutable.", + "Known problems": "None.", + "Example": "```rust\nfn x(r: &i32) {\n unsafe {\n *(r as *const _ as *mut _) += 1;\n }\n}\n```\n\nInstead consider using interior mutability types.\n\n```rust\nfn x(r: &UnsafeCell) {\n unsafe {\n *r.get() += 1;\n }\n}\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\", *y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\nx == NAN\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```rust\nif x == ptr::null {\n ..\n}\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```rust\nconst 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```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n // `*t` or `&t`'s\n```" + } + }, + { + "id": "cyclomatic_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cyclomatic complexity.", + "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "dbg_macro", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of dbg!() macro.", + "Why is this bad": "`dbg!` macro is intended as a debugging tool. It\nshould not be in version control.", + "Known problems": "None.", + "Example": "```rust,ignore\n// Bad\ndbg!(true)\n\n// Good\ntrue\n```" + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_cfg_attr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.", + "Why is this bad": "Since 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.", + "Known problems": "This 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)", + "Example": "Bad:\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nGood:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n \"CamelCase\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simplified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```rust\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0,\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nx + 1 == x + 1\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g. `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\n0 / x;\n0 * x;\nx & 0\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {\n x = 1;\n 1\n} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet v: f32 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789\n\n// Good\nlet v: f64 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() {\n ..\n}\n```\ncan be rewritten to\n```rust\nfor x in y {\n ..\n}\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() {\n ..\n}\n```\ncan be rewritten to\n```rust\nfor x in &y {\n ..\n}\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) {\n ..\n}\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE = 1.00f64;\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 {}\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 {}\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 {\n 1\n};\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 {\n 1\n};\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```rust\nfor (k, _) in &map {\n ..\n}\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in option {\n ..\n}\n```\n\nThis should be\n```rust\nif let Some(x) = option {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in result {\n ..\n}\n```\n\nThis should be\n```rust\nif let Ok(x) = result {\n ..\n}\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "Not a replacement for error handling: Using either\n`.unwrap()` or the Index trait (`[]`) carries the risk of causing a `panic`\nif the value being accessed is `None`. If the use of `.get().unwrap()` is a\ntemporary placeholder for dealing with the `Option` type, then this does\nnot mitigate the need for error handling. If there is a chance that `.get()`\nwill be `None` in your program, then it is advisable that the `None` case\nis handled in a future refactor instead of using `.unwrap()` or the Index\ntrait.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g. `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "The original rule will only lint for `if let`. After\nmaking it support to lint `match`, naming as `if let` is not suitable for it.\nSo, this lint is deprecated." + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```" + } + }, + { + "id": "implicit_return", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for missing return statements at the end of a block.", + "Why is this bad": "Actually omitting the return keyword is idiomatic Rust code. Programmers\ncoming from other languages might prefer the expressiveness of `return`. It's possible to miss\nthe last returning statement because the only difference is a missing `;`. Especially in bigger\ncode with multiple return paths having a `return` keyword makes it easier to find the\ncorresponding statements.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: usize) {\n x\n}\n```\nadd return\n```rust\nfn foo(x: usize) {\n return x;\n}\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\n618_64_9189_73_511\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "into_iter_on_array", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `into_iter` calls on types which should be replaced by `iter` or\n`iter_mut`.", + "Why is this bad": "Arrays and `PathBuf` do not yet have an `into_iter` method which move out\ntheir content into an iterator. Auto-referencing resolves the `into_iter` call to its reference\ninstead, like `<&[T; N] as IntoIterator>::into_iter`, which just iterates over item references\nlike calling `iter` would. Furthermore, when the standard library actually\n[implements the `into_iter` method][25725] which moves the content out of the array, the\noriginal use of `into_iter` got inferred with the wrong type and the code will be broken.", + "Known problems": "None", + "Example": "```rust\nlet _ = [1, 2, 3].into_iter().map(|x| *x).collect::>();\n```\n\n[25725]: https://github.com/rust-lang/rust/issues/25725" + } + }, + { + "id": "into_iter_on_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `into_iter` calls on references which should be replaced by `iter`\nor `iter_mut`.", + "Why is this bad": "Readability. Calling `into_iter` on a reference will not move out its\ncontent into the resulting iterator, which is confusing. It is better just call `iter` or\n`iter_mut` directly.", + "Known problems": "None", + "Example": "```rust\nlet _ = (&vec![3, 4, 5]).into_iter();\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```rust\nfor x in y.next() {\n ..\n}\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```rust\nfor x in (5..5).step_by(0) {\n ..\n}\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\n6186491_8973511\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a enum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize {\n ..\n }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```rust\nif x.len() == 0 {\n ..\n}\nif y.len() != 0 {\n ..\n}\n```\ninstead use\n```rust\nif x.is_empty() {\n ..\n}\nif !y.is_empty() {\n ..\n}\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = {\n 1;\n};\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) {\n m.insert(k.clone(), v);\n}\n```", + "Example": "```rust\nif !m.contains_key(&k) {\n m.insert(k, v)\n}\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\niter.map(|x| x.iter()).flatten()\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1...10 => println!(\"1 ... 10\"),\n 5...15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x: Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_discriminant_non_enum", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `mem::discriminant()` on a non-enum type.", + "Why is this bad": "The value of `mem::discriminant()` on non-enum types\nis unspecified.", + "Known problems": "None.", + "Example": "```rust\nmem::discriminant(&\"hello\");\nmem::discriminant(&&Some(2));\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_const_for_fn", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Suggests the use of `const` in functions and methods where possible.", + "Why is this bad": "Not having the function const prevents callers of the function from being const as well.", + "Known problems": "Const 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.", + "Example": "```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```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make\nsense. It allows the crate to require all exported methods to be `#[inline]` by default, and\nthen opt out for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "module_name_repetitions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nx % 1\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::sync::atomic::AtomicBool` and `std::sync::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::sync::atomic::AtomicUsize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x {\n false\n} else {\n true\n}\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "None." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\nlet mut v = Vec::::new();\nlet _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 {\n x\n}\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) {\n return x;\n}\n```\nsimplify to\n```rust\nfn foo(x: usize) {\n x\n}\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint {\n x: 1,\n y: 0,\n ..zero_point\n}\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g. `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```rust\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop {\n ..;\n break;\n}\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).\n\nIt detects both the case when a manual\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\nimplementation is required and also when it can be created with\n`#[derive(Default)]`", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nOr, if\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\ncan be derived by `#[derive(Default)]`:\n\n```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nInstead, use:\n\n```rust\n#[derive(Default)]\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) {\n println!(\"{}\", unsafe { *x });\n}\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```rust\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet x = [1, 2, 3, 4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```rust\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.offset(offset as isize);\n}\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.add(offset);\n}\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator", + "Why is this bad": "Question mark usage is more idiomatic", + "Known problems": "None", + "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e: `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_clone", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for a redudant `clone()` (and its relatives) which clones an owned\nvalue that is going to be dropped without further use.", + "Why is this bad": "It is not always possible for the compiler to eliminate useless\nallocations and deallocations generated by redundant `clone()`s.", + "Known problems": "* Suggestions made by this lint could require NLL to be enabled.\n* False-positive if there is a borrow preventing the value from moving out.\n\n```rust\nlet x = String::new();\n\nlet y = &x;\n\nfoo(x.clone()); // This lint suggests to remove this `clone()`\n```", + "Example": "```rust\n{\n let x = Foo::new();\n call(x.clone());\n call(x.clone()); // this can just pass `x`\n}\n\n[\"lorem\", \"ipsum\"].join(\" \").to_string()\n\nPath::new(\"/a/b\").join(\"c\").to_path_buf()\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee https://github.com/rust-lang/rust-clippy/issues/1439 for more\ndetails.", + "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```rust\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```rust\nfor x in 5..10 - 5 {\n ..\n} // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y;\nlet x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend\nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X {\n ..\n }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => (),\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let else` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "Using `match`:\n\n```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```\n\nUsing `if let` with `else`:\n\n```rust\nif let Some(ref foo) = x {\n bar(foo);\n} else {\n bar(other_ref);\n}\n```" + } + }, + { + "id": "slow_vector_initialization", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks slow zero-filled vector initialization", + "Why is this bad": "These structures are non-idiomatic and less efficient than simply using\n`vec![0; len]`.", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nvec1.resize(len, 0);\n\nlet mut vec2 = Vec::with_capacity(len);\nvec2.extend(repeat(0).take(len))\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else`. It lints if the `else`\nis followed immediately by a newline or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} { // looks like an `else` is missing here\n}\n\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\n{ // this is the `else` block of the previous `if`, but should it be?\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n ..\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "too_many_lines", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions with a large amount of lines.", + "Why is this bad": "Functions with a lot of lines are harder to understand\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.", + "Known problems": "None.", + "Example": "``` rust\nfn im_too_long() {\nprintln!(\"\");\n// ... 100 more LoC\nprintln!(\"\");\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-lines-threshold: u64`: The maximum number of lines a function or method can have (defaults to `100 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool {\n ..\n}\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "Transmutes are dangerous and error-prone, whereas `from_bits` is intuitive\nand safe.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```rust\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a\nunit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif {\n foo();\n} == {\n bar();\n} {\n baz();\n}\n```\nis equal to\n```rust\n{\n foo();\n bar();\n baz();\n}\n```" + } + }, + { + "id": "unknown_clippy_lints", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `allow`/`warn`/`deny`/`forbid` attributes with scoped clippy\nlints and if those lints exist in clippy. If there is a uppercase letter in the lint name\n(not the tool name) and a lowercase version of this lint exists, it will suggest to lowercase\nthe lint name.", + "Why is this bad": "A lint attribute with a mistyped lint name won't have an effect.", + "Known problems": "None.", + "Example": "Bad:\n```rust\n#![warn(if_not_els)]\n#![deny(clippy::All)]\n```\n\nGood:\n```rust\n#![warn(if_not_else)]\n#![deny(clippy::all)]\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```rust\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\n61864918973511\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unsafe_vector_initialization", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint used to suggest replacing `let mut vec =\nVec::with_capacity(n); vec.set_len(n);` with `let vec = vec![0; n];`. The\nreplacement has very different performance characteristics so the lint is\ndeprecated." + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g. the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () {\n ()\n}\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "- False positive when using associated types (#2843)\n- False positives in some situations when using generics (#3410)", + "Example": "```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```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"foo\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "vec_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Vec>` where T: Sized anywhere in the code.", + "Why is this bad": "`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.", + "Known problems": "Vec> makes sense if T is a large type (see #3530,\n1st comment).", + "Example": "```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nx & 0x1111 == 0\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```rust\nwhile let Some(val) = iter() {\n ..\n}\n```" + } + }, + { + "id": "wildcard_dependencies", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard dependencies in the `Cargo.toml`.", + "Why is this bad": "[As the edition guide says](https://rust-lang-nursery.github.io/edition-guide/rust-2018/cargo-and-crates-io/crates-io-disallows-wildcard-dependencies.html),\nit is highly unlikely that you work with any possible version of your dependency,\nand wildcard dependencies would cause unnecessary breakage in the ecosystem.", + "Known problems": "None.", + "Example": "```toml\n[dependencies]\nregex = \"*\"\n```" + } + }, + { + "id": "wildcard_enum_match_arm", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard enum matches using `_`.", + "Why is this bad": "New enum variants added by library updates can be missed.", + "Known problems": "Suggested replacements may be incorrect if guards exhaustively cover some\nvariants, and also may not use correct path to enum if it's not present in the current scope.", + "Example": "```rust\nmatch x {\n A => {},\n _ => {},\n}\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(\"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\n0 as *const u32\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.34.1/index.html b/rust-1.34.1/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.34.1/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.34.1/lints.json b/rust-1.34.1/lints.json new file mode 100644 index 000000000000..357685eec84c --- /dev/null +++ b/rust-1.34.1/lints.json @@ -0,0 +1,3364 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust,ignore\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assertions_on_constants", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Check to call assert!(true/false)", + "Why is this bad": "Will be optimized out by the compiler or should probably be replaced by a\npanic!() or unreachable!()", + "Known problems": "None", + "Example": "```rust\nassert!(false)\n// or\nassert!(true)\n// or\nconst B: bool = false;\nassert!(B)\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint is too subjective, not having a good reason for being in clippy.\nAdditionally, compound assignment operators may be overloaded separately from their non-assigning\ncounterparts, so this lint may suggest a change in behavior or the code may not compile." + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } ..\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true`,\n`x != true` and order comparisons such as `x < true` (or vice versa) and\nsuggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true {} // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cargo_common_metadata", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks 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", + "Why is this bad": "It will be more difficult for users to discover the\npurpose of the crate, and key information related to it.", + "Known problems": "None.", + "Example": "```toml\n# This `Cargo.toml` is missing an authors field:\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/Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 {\n x as u64\n}\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 {\n u64::from(x)\n}\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 {\n x as u8\n}\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX;\nx as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_ref_to_mut", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of `&T` to `&mut T` anywhere in the code.", + "Why is this bad": "It\u2019s basically guaranteed to be undefined behaviour.\n`UnsafeCell` is the only way to obtain aliasable data that is considered\nmutable.", + "Known problems": "None.", + "Example": "```rust\nfn x(r: &i32) {\n unsafe {\n *(r as *const _ as *mut _) += 1;\n }\n}\n```\n\nInstead consider using interior mutability types.\n\n```rust\nfn x(r: &UnsafeCell) {\n unsafe {\n *r.get() += 1;\n }\n}\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\", *y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\nx == NAN\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```rust\nif x == ptr::null {\n ..\n}\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```rust\nconst 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```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n // `*t` or `&t`'s\n```" + } + }, + { + "id": "cyclomatic_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cyclomatic complexity.", + "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "dbg_macro", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of dbg!() macro.", + "Why is this bad": "`dbg!` macro is intended as a debugging tool. It\nshould not be in version control.", + "Known problems": "None.", + "Example": "```rust,ignore\n// Bad\ndbg!(true)\n\n// Good\ntrue\n```" + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_cfg_attr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.", + "Why is this bad": "Since 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.", + "Known problems": "This 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)", + "Example": "Bad:\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nGood:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n \"CamelCase\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simplified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```rust\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0,\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nx + 1 == x + 1\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g. `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\n0 / x;\n0 * x;\nx & 0\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {\n x = 1;\n 1\n} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet v: f32 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789\n\n// Good\nlet v: f64 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() {\n ..\n}\n```\ncan be rewritten to\n```rust\nfor x in y {\n ..\n}\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() {\n ..\n}\n```\ncan be rewritten to\n```rust\nfor x in &y {\n ..\n}\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) {\n ..\n}\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE = 1.00f64;\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 {}\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 {}\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 {\n 1\n};\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 {\n 1\n};\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```rust\nfor (k, _) in &map {\n ..\n}\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in option {\n ..\n}\n```\n\nThis should be\n```rust\nif let Some(x) = option {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in result {\n ..\n}\n```\n\nThis should be\n```rust\nif let Ok(x) = result {\n ..\n}\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "Not a replacement for error handling: Using either\n`.unwrap()` or the Index trait (`[]`) carries the risk of causing a `panic`\nif the value being accessed is `None`. If the use of `.get().unwrap()` is a\ntemporary placeholder for dealing with the `Option` type, then this does\nnot mitigate the need for error handling. If there is a chance that `.get()`\nwill be `None` in your program, then it is advisable that the `None` case\nis handled in a future refactor instead of using `.unwrap()` or the Index\ntrait.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g. `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "The original rule will only lint for `if let`. After\nmaking it support to lint `match`, naming as `if let` is not suitable for it.\nSo, this lint is deprecated." + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```" + } + }, + { + "id": "implicit_return", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for missing return statements at the end of a block.", + "Why is this bad": "Actually omitting the return keyword is idiomatic Rust code. Programmers\ncoming from other languages might prefer the expressiveness of `return`. It's possible to miss\nthe last returning statement because the only difference is a missing `;`. Especially in bigger\ncode with multiple return paths having a `return` keyword makes it easier to find the\ncorresponding statements.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: usize) {\n x\n}\n```\nadd return\n```rust\nfn foo(x: usize) {\n return x;\n}\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\n618_64_9189_73_511\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "into_iter_on_array", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `into_iter` calls on types which should be replaced by `iter` or\n`iter_mut`.", + "Why is this bad": "Arrays and `PathBuf` do not yet have an `into_iter` method which move out\ntheir content into an iterator. Auto-referencing resolves the `into_iter` call to its reference\ninstead, like `<&[T; N] as IntoIterator>::into_iter`, which just iterates over item references\nlike calling `iter` would. Furthermore, when the standard library actually\n[implements the `into_iter` method][25725] which moves the content out of the array, the\noriginal use of `into_iter` got inferred with the wrong type and the code will be broken.", + "Known problems": "None", + "Example": "```rust\nlet _ = [1, 2, 3].into_iter().map(|x| *x).collect::>();\n```\n\n[25725]: https://github.com/rust-lang/rust/issues/25725" + } + }, + { + "id": "into_iter_on_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `into_iter` calls on references which should be replaced by `iter`\nor `iter_mut`.", + "Why is this bad": "Readability. Calling `into_iter` on a reference will not move out its\ncontent into the resulting iterator, which is confusing. It is better just call `iter` or\n`iter_mut` directly.", + "Known problems": "None", + "Example": "```rust\nlet _ = (&vec![3, 4, 5]).into_iter();\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```rust\nfor x in y.next() {\n ..\n}\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```rust\nfor x in (5..5).step_by(0) {\n ..\n}\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\n6186491_8973511\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a enum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize {\n ..\n }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```rust\nif x.len() == 0 {\n ..\n}\nif y.len() != 0 {\n ..\n}\n```\ninstead use\n```rust\nif x.is_empty() {\n ..\n}\nif !y.is_empty() {\n ..\n}\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = {\n 1;\n};\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) {\n m.insert(k.clone(), v);\n}\n```", + "Example": "```rust\nif !m.contains_key(&k) {\n m.insert(k, v)\n}\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\niter.map(|x| x.iter()).flatten()\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1...10 => println!(\"1 ... 10\"),\n 5...15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x: Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_discriminant_non_enum", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `mem::discriminant()` on a non-enum type.", + "Why is this bad": "The value of `mem::discriminant()` on non-enum types\nis unspecified.", + "Known problems": "None.", + "Example": "```rust\nmem::discriminant(&\"hello\");\nmem::discriminant(&&Some(2));\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_const_for_fn", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Suggests the use of `const` in functions and methods where possible.", + "Why is this bad": "Not having the function const prevents callers of the function from being const as well.", + "Known problems": "Const 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.", + "Example": "```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```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make\nsense. It allows the crate to require all exported methods to be `#[inline]` by default, and\nthen opt out for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "module_name_repetitions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nx % 1\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::sync::atomic::AtomicBool` and `std::sync::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::sync::atomic::AtomicUsize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x {\n false\n} else {\n true\n}\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "None." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\nlet mut v = Vec::::new();\nlet _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 {\n x\n}\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) {\n return x;\n}\n```\nsimplify to\n```rust\nfn foo(x: usize) {\n x\n}\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint {\n x: 1,\n y: 0,\n ..zero_point\n}\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g. `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```rust\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop {\n ..;\n break;\n}\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).\n\nIt detects both the case when a manual\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\nimplementation is required and also when it can be created with\n`#[derive(Default)]`", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nOr, if\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\ncan be derived by `#[derive(Default)]`:\n\n```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nInstead, use:\n\n```rust\n#[derive(Default)]\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) {\n println!(\"{}\", unsafe { *x });\n}\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```rust\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet x = [1, 2, 3, 4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```rust\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.offset(offset as isize);\n}\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.add(offset);\n}\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator", + "Why is this bad": "Question mark usage is more idiomatic", + "Known problems": "None", + "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e: `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_clone", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for a redudant `clone()` (and its relatives) which clones an owned\nvalue that is going to be dropped without further use.", + "Why is this bad": "It is not always possible for the compiler to eliminate useless\nallocations and deallocations generated by redundant `clone()`s.", + "Known problems": "* Suggestions made by this lint could require NLL to be enabled.\n* False-positive if there is a borrow preventing the value from moving out.\n\n```rust\nlet x = String::new();\n\nlet y = &x;\n\nfoo(x.clone()); // This lint suggests to remove this `clone()`\n```", + "Example": "```rust\n{\n let x = Foo::new();\n call(x.clone());\n call(x.clone()); // this can just pass `x`\n}\n\n[\"lorem\", \"ipsum\"].join(\" \").to_string()\n\nPath::new(\"/a/b\").join(\"c\").to_path_buf()\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee https://github.com/rust-lang/rust-clippy/issues/1439 for more\ndetails.", + "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```rust\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```rust\nfor x in 5..10 - 5 {\n ..\n} // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y;\nlet x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend\nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X {\n ..\n }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => (),\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let else` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "Using `match`:\n\n```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```\n\nUsing `if let` with `else`:\n\n```rust\nif let Some(ref foo) = x {\n bar(foo);\n} else {\n bar(other_ref);\n}\n```" + } + }, + { + "id": "slow_vector_initialization", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks slow zero-filled vector initialization", + "Why is this bad": "These structures are non-idiomatic and less efficient than simply using\n`vec![0; len]`.", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nvec1.resize(len, 0);\n\nlet mut vec2 = Vec::with_capacity(len);\nvec2.extend(repeat(0).take(len))\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else`. It lints if the `else`\nis followed immediately by a newline or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} { // looks like an `else` is missing here\n}\n\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\n{ // this is the `else` block of the previous `if`, but should it be?\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n ..\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "too_many_lines", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions with a large amount of lines.", + "Why is this bad": "Functions with a lot of lines are harder to understand\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.", + "Known problems": "None.", + "Example": "``` rust\nfn im_too_long() {\nprintln!(\"\");\n// ... 100 more LoC\nprintln!(\"\");\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-lines-threshold: u64`: The maximum number of lines a function or method can have (defaults to `100 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool {\n ..\n}\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "Transmutes are dangerous and error-prone, whereas `from_bits` is intuitive\nand safe.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```rust\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a\nunit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif {\n foo();\n} == {\n bar();\n} {\n baz();\n}\n```\nis equal to\n```rust\n{\n foo();\n bar();\n baz();\n}\n```" + } + }, + { + "id": "unknown_clippy_lints", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `allow`/`warn`/`deny`/`forbid` attributes with scoped clippy\nlints and if those lints exist in clippy. If there is a uppercase letter in the lint name\n(not the tool name) and a lowercase version of this lint exists, it will suggest to lowercase\nthe lint name.", + "Why is this bad": "A lint attribute with a mistyped lint name won't have an effect.", + "Known problems": "None.", + "Example": "Bad:\n```rust\n#![warn(if_not_els)]\n#![deny(clippy::All)]\n```\n\nGood:\n```rust\n#![warn(if_not_else)]\n#![deny(clippy::all)]\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```rust\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\n61864918973511\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unsafe_vector_initialization", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint used to suggest replacing `let mut vec =\nVec::with_capacity(n); vec.set_len(n);` with `let vec = vec![0; n];`. The\nreplacement has very different performance characteristics so the lint is\ndeprecated." + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g. the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () {\n ()\n}\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "- False positive when using associated types (#2843)\n- False positives in some situations when using generics (#3410)", + "Example": "```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```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"foo\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "vec_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Vec>` where T: Sized anywhere in the code.", + "Why is this bad": "`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.", + "Known problems": "Vec> makes sense if T is a large type (see #3530,\n1st comment).", + "Example": "```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nx & 0x1111 == 0\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```rust\nwhile let Some(val) = iter() {\n ..\n}\n```" + } + }, + { + "id": "wildcard_dependencies", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard dependencies in the `Cargo.toml`.", + "Why is this bad": "[As the edition guide says](https://rust-lang-nursery.github.io/edition-guide/rust-2018/cargo-and-crates-io/crates-io-disallows-wildcard-dependencies.html),\nit is highly unlikely that you work with any possible version of your dependency,\nand wildcard dependencies would cause unnecessary breakage in the ecosystem.", + "Known problems": "None.", + "Example": "```toml\n[dependencies]\nregex = \"*\"\n```" + } + }, + { + "id": "wildcard_enum_match_arm", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard enum matches using `_`.", + "Why is this bad": "New enum variants added by library updates can be missed.", + "Known problems": "Suggested replacements may be incorrect if guards exhaustively cover some\nvariants, and also may not use correct path to enum if it's not present in the current scope.", + "Example": "```rust\nmatch x {\n A => {},\n _ => {},\n}\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(\"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\n0 as *const u32\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.34.2/index.html b/rust-1.34.2/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.34.2/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.34.2/lints.json b/rust-1.34.2/lints.json new file mode 100644 index 000000000000..357685eec84c --- /dev/null +++ b/rust-1.34.2/lints.json @@ -0,0 +1,3364 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g. 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nvec.len() <= 0\n100 > std::i32::MAX\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust,ignore\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assertions_on_constants", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Check to call assert!(true/false)", + "Why is this bad": "Will be optimized out by the compiler or should probably be replaced by a\npanic!() or unreachable!()", + "Known problems": "None", + "Example": "```rust\nassert!(false)\n// or\nassert!(true)\n// or\nconst B: bool = false;\nassert!(B)\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\n...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint is too subjective, not having a good reason for being in clippy.\nAdditionally, compound assignment operators may be overloaded separately from their non-assigning\ncounterparts, so this lint may suggest a change in behavior or the code may not compile." + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { \u2026 }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } ..\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```rust\nif { let x = somefunc(); x } ..\n// or\nif somefunc(|x| { x == 47 }) ..\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true`,\n`x != true` and order comparisons such as `x < true` (or vice versa) and\nsuggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true {} // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.\ncontains a `Cell`, `Mutex`, `AtomicXxxx` etc) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cargo_common_metadata", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks 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", + "Why is this bad": "It will be more difficult for users to discover the\npurpose of the crate, and key information related to it.", + "Known problems": "None.", + "Example": "```toml\n# This `Cargo.toml` is missing an authors field:\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/Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 {\n x as u64\n}\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 {\n u64::from(x)\n}\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 {\n x as u8\n}\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e. nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX;\nx as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_ref_to_mut", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of `&T` to `&mut T` anywhere in the code.", + "Why is this bad": "It\u2019s basically guaranteed to be undefined behaviour.\n`UnsafeCell` is the only way to obtain aliasable data that is considered\nmutable.", + "Known problems": "None.", + "Example": "```rust\nfn x(r: &i32) {\n unsafe {\n *(r as *const _ as *mut _) += 1;\n }\n}\n```\n\nInstead consider using interior mutability types.\n\n```rust\nfn x(r: &UnsafeCell) {\n unsafe {\n *r.get() += 1;\n }\n}\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\", *y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g. `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\nx == NAN\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```rust\nif x == ptr::null {\n ..\n}\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```rust\nconst 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```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n // `*t` or `&t`'s\n```" + } + }, + { + "id": "cyclomatic_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cyclomatic complexity.", + "Why is this bad": "Methods of high cyclomatic complexity tend to be badly\nreadable. Also LLVM will usually optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cyclomatic-complexity-threshold: u64`: The maximum cyclomatic complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "dbg_macro", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of dbg!() macro.", + "Why is this bad": "`dbg!` macro is intended as a debugging tool. It\nshould not be in version control.", + "Known problems": "None.", + "Example": "```rust,ignore\n// Bad\ndbg!(true)\n\n// Good\ntrue\n```" + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g. contains a `Cell`, `Mutex`, `AtomicXxxx` etc).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g. the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_cfg_attr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.", + "Why is this bad": "Since 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.", + "Known problems": "This 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)", + "Example": "Bad:\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nGood:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else(..) { ... }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```rust\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```rust\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n \"CamelCase\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simplified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g. MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // we don't care about zero\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```rust\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0,\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nx + 1 == x + 1\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g. `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\n0 / x;\n0 * x;\nx & 0\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {\n x = 1;\n 1\n} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet v: f32 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789\n\n// Good\nlet v: f64 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() {\n ..\n}\n```\ncan be rewritten to\n```rust\nfor x in y {\n ..\n}\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() {\n ..\n}\n```\ncan be rewritten to\n```rust\nfor x in &y {\n ..\n}\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) {\n ..\n}\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\ny == 1.23f64\ny != x // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE = 1.00f64;\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 {}\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 {}\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 {\n 1\n};\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 {\n 1\n};\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```rust\nfor (k, _) in &map {\n ..\n}\n```\n\ncould be replaced by\n\n```rust\nfor k in map.keys() {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in option {\n ..\n}\n```\n\nThis should be\n```rust\nif let Some(x) = option {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```rust\nfor x in result {\n ..\n}\n```\n\nThis should be\n```rust\nif let Ok(x) = result {\n ..\n}\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "Not a replacement for error handling: Using either\n`.unwrap()` or the Index trait (`[]`) carries the risk of causing a `panic`\nif the value being accessed is `None`. If the use of `.get().unwrap()` is a\ntemporary placeholder for dealing with the `Option` type, then this does\nnot mitigate the need for error handling. If there is a chance that `.get()`\nwill be `None` in your program, then it is advisable that the `None` case\nis handled in a future refactor instead of using `.unwrap()` or the Index\ntrait.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g. `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "The original rule will only lint for `if let`. After\nmaking it support to lint `match`, naming as `if let` is not suitable for it.\nSo, this lint is deprecated." + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```rust\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```rust\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```rust\nif a == b {\n \u2026\n} else if a == b {\n \u2026\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 \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { ... }\n\npub foo(map: &mut HashMap) { .. }\n```" + } + }, + { + "id": "implicit_return", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for missing return statements at the end of a block.", + "Why is this bad": "Actually omitting the return keyword is idiomatic Rust code. Programmers\ncoming from other languages might prefer the expressiveness of `return`. It's possible to miss\nthe last returning statement because the only difference is a missing `;`. Especially in bigger\ncode with multiple return paths having a `return` keyword makes it easier to find the\ncorresponding statements.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: usize) {\n x\n}\n```\nadd return\n```rust\nfn foo(x: usize) {\n return x;\n}\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\n618_64_9189_73_511\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { \u2026 }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```rust\nrepeat(1_u8).iter().collect::>()\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```rust\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "into_iter_on_array", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `into_iter` calls on types which should be replaced by `iter` or\n`iter_mut`.", + "Why is this bad": "Arrays and `PathBuf` do not yet have an `into_iter` method which move out\ntheir content into an iterator. Auto-referencing resolves the `into_iter` call to its reference\ninstead, like `<&[T; N] as IntoIterator>::into_iter`, which just iterates over item references\nlike calling `iter` would. Furthermore, when the standard library actually\n[implements the `into_iter` method][25725] which moves the content out of the array, the\noriginal use of `into_iter` got inferred with the wrong type and the code will be broken.", + "Known problems": "None", + "Example": "```rust\nlet _ = [1, 2, 3].into_iter().map(|x| *x).collect::>();\n```\n\n[25725]: https://github.com/rust-lang/rust/issues/25725" + } + }, + { + "id": "into_iter_on_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `into_iter` calls on references which should be replaced by `iter`\nor `iter_mut`.", + "Why is this bad": "Readability. Calling `into_iter` on a reference will not move out its\ncontent into the resulting iterator, which is confusing. It is better just call `iter` or\n`iter_mut` directly.", + "Known problems": "None", + "Example": "```rust\nlet _ = (&vec![3, 4, 5]).into_iter();\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```rust\nlet bad_ref: &usize = std::mem::zeroed();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```rust\nfor x in y.next() {\n ..\n}\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```rust\nfor x in (5..5).step_by(0) {\n ..\n}\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\n6186491_8973511\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a enum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n pub fn len(&self) -> usize {\n ..\n }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```rust\nif x.len() == 0 {\n ..\n}\nif y.len() != 0 {\n ..\n}\n```\ninstead use\n```rust\nif x.is_empty() {\n ..\n}\nif !y.is_empty() {\n ..\n}\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = {\n 1;\n};\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```rust\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) {\n m.insert(k.clone(), v);\n}\n```", + "Example": "```rust\nif !m.contains_key(&k) {\n m.insert(k, v)\n}\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\niter.map(|x| x.iter()).flatten()\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1...10 => println!(\"1 ... 10\"),\n 5...15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x: Result(i32, &str) = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g. in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_discriminant_non_enum", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `mem::discriminant()` on a non-enum type.", + "Why is this bad": "The value of `mem::discriminant()` on non-enum types\nis unspecified.", + "Known problems": "None.", + "Example": "```rust\nmem::discriminant(&\"hello\");\nmem::discriminant(&&Some(2));\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```rust\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_const_for_fn", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Suggests the use of `const` in functions and methods where possible.", + "Why is this bad": "Not having the function const prevents callers of the function from being const as well.", + "Known problems": "Const 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.", + "Example": "```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```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make\nsense. It allows the crate to require all exported methods to be `#[inline]` by default, and\nthen opt out for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```rust\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "module_name_repetitions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nx % 1\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::sync::atomic::AtomicBool` and `std::sync::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::sync::atomic::AtomicUsize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x {\n false\n} else {\n true\n}\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "None." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\nlet mut v = Vec::::new();\nlet _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 {\n x\n}\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) {\n return x;\n}\n```\nsimplify to\n```rust\nfn foo(x: usize) {\n x\n}\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint {\n x: 1,\n y: 0,\n ..zero_point\n}\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g. `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```rust\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop {\n ..;\n break;\n}\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```rust\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).\n\nIt detects both the case when a manual\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\nimplementation is required and also when it can be created with\n`#[derive(Default)]`", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```rust\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```rust\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nOr, if\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\ncan be derived by `#[derive(Default)]`:\n\n```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nInstead, use:\n\n```rust\n#[derive(Default)]\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```rust\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nOpenOptions::new().read(true).truncate(true)\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) {\n println!(\"{}\", unsafe { *x });\n}\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```rust\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```rust\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```rust\nlet x = [1, 2, 3, 4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```rust\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```rust\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.offset(offset as isize);\n}\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.add(offset);\n}\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator", + "Why is this bad": "Question mark usage is more idiomatic", + "Known problems": "None", + "Example": "```rust\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```rust\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g. `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g. `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e: `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_clone", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for a redudant `clone()` (and its relatives) which clones an owned\nvalue that is going to be dropped without further use.", + "Why is this bad": "It is not always possible for the compiler to eliminate useless\nallocations and deallocations generated by redundant `clone()`s.", + "Known problems": "* Suggestions made by this lint could require NLL to be enabled.\n* False-positive if there is a borrow preventing the value from moving out.\n\n```rust\nlet x = String::new();\n\nlet y = &x;\n\nfoo(x.clone()); // This lint suggests to remove this `clone()`\n```", + "Example": "```rust\n{\n let x = Foo::new();\n call(x.clone());\n call(x.clone()); // this can just pass `x`\n}\n\n[\"lorem\", \"ipsum\"].join(\" \").to_string()\n\nPath::new(\"/a/b\").join(\"c\").to_path_buf()\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee https://github.com/rust-lang/rust-clippy/issues/1439 for more\ndetails.", + "Example": "```rust\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```rust\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```rust\nfor x in 5..10 - 5 {\n ..\n} // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y;\nlet x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend\nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X {\n ..\n }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```rust\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g. `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => (),\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let else` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "Using `match`:\n\n```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```\n\nUsing `if let` with `else`:\n\n```rust\nif let Some(ref foo) = x {\n bar(foo);\n} else {\n bar(other_ref);\n}\n```" + } + }, + { + "id": "slow_vector_initialization", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks slow zero-filled vector initialization", + "Why is this bad": "These structures are non-idiomatic and less efficient than simply using\n`vec![0; len]`.", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nvec1.resize(len, 0);\n\nlet mut vec2 = Vec::with_capacity(len);\nvec2.extend(repeat(0).take(len))\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def));\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g. `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else`. It lints if the `else`\nis followed immediately by a newline or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} { // looks like an `else` is missing here\n}\n\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\n{ // this is the `else` block of the previous `if`, but should it be?\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```rust\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n ..\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "too_many_lines", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions with a large amount of lines.", + "Why is this bad": "Functions with a lot of lines are harder to understand\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.", + "Known problems": "None.", + "Example": "``` rust\nfn im_too_long() {\nprintln!(\"\");\n// ... 100 more LoC\nprintln!(\"\");\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-lines-threshold: u64`: The maximum number of lines a function or method can have (defaults to `100 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g. changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool {\n ..\n}\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "Transmutes are dangerous and error-prone, whereas `from_bits` is intuitive\nand safe.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```rust\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```rust\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a\nunit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif {\n foo();\n} == {\n bar();\n} {\n baz();\n}\n```\nis equal to\n```rust\n{\n foo();\n bar();\n baz();\n}\n```" + } + }, + { + "id": "unknown_clippy_lints", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `allow`/`warn`/`deny`/`forbid` attributes with scoped clippy\nlints and if those lints exist in clippy. If there is a uppercase letter in the lint name\n(not the tool name) and a lowercase version of this lint exists, it will suggest to lowercase\nthe lint name.", + "Why is this bad": "A lint attribute with a mistyped lint name won't have an effect.", + "Known problems": "None.", + "Example": "Bad:\n```rust\n#![warn(if_not_els)]\n#![deny(clippy::All)]\n```\n\nGood:\n```rust\n#![warn(if_not_else)]\n#![deny(clippy::all)]\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```rust\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```rust\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\n61864918973511\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unsafe_vector_initialization", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint used to suggest replacing `let mut vec =\nVec::with_capacity(n); vec.set_len(n);` with `let vec = vec![0; n];`. The\nreplacement has very different performance characteristics so the lint is\ndeprecated." + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g. the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () {\n ()\n}\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "- False positive when using associated types (#2843)\n- False positives in some situations when using generics (#3410)", + "Example": "```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```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```rust\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"foo\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "vec_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Vec>` where T: Sized anywhere in the code.", + "Why is this bad": "`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.", + "Known problems": "Vec> makes sense if T is a large type (see #3530,\n1st comment).", + "Example": "```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nx & 0x1111 == 0\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```rust\nwhile let Some(val) = iter() {\n ..\n}\n```" + } + }, + { + "id": "wildcard_dependencies", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard dependencies in the `Cargo.toml`.", + "Why is this bad": "[As the edition guide says](https://rust-lang-nursery.github.io/edition-guide/rust-2018/cargo-and-crates-io/crates-io-disallows-wildcard-dependencies.html),\nit is highly unlikely that you work with any possible version of your dependency,\nand wildcard dependencies would cause unnecessary breakage in the ecosystem.", + "Known problems": "None.", + "Example": "```toml\n[dependencies]\nregex = \"*\"\n```" + } + }, + { + "id": "wildcard_enum_match_arm", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard enum matches using `_`.", + "Why is this bad": "New enum variants added by library updates can be missed.", + "Known problems": "Suggested replacements may be incorrect if guards exhaustively cover some\nvariants, and also may not use correct path to enum if it's not present in the current scope.", + "Example": "```rust\nmatch x {\n A => {},\n _ => {},\n}\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(\"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```rust\nimpl X {\n fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```rust\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\n0 as *const u32\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.35.0/index.html b/rust-1.35.0/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.35.0/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.35.0/lints.json b/rust-1.35.0/lints.json new file mode 100644 index 000000000000..bce2ee5c38f0 --- /dev/null +++ b/rust-1.35.0/lints.json @@ -0,0 +1,3364 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g., 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nlet vec: Vec = vec![];\nif vec.len() <= 0 {}\nif 100 > std::i32::MAX {}\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "If you happen to have a value that is within 1/8192 of a\nknown constant, but is not *and should not* be the same, this lint will\nreport your value anyway. We have not yet noticed any false positives in\ncode we tested clippy with (this includes servo), but YMMV.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assertions_on_constants", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `assert!(true)` and `assert!(false)` calls.", + "Why is this bad": "Will be optimized out by the compiler or should probably be replaced by a\npanic!() or unreachable!()", + "Known problems": "None", + "Example": "```rust,ignore\nassert!(false)\n// or\nassert!(true)\n// or\nconst B: bool = false;\nassert!(B)\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\nlet b = 0;\n// ...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } { /* ... */ }\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```ignore\nif { let x = somefunc(); x } {}\n// or\nif somefunc(|x| { x == 47 }) {}\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true`,\n`x != true` and order comparisons such as `x < true` (or vice versa) and\nsuggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true {} // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.,\ncontains a `Cell`, `Mutex`, `AtomicXxxx`, etc.) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust,ignore\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust,ignore\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust,ignore\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cargo_common_metadata", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks 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", + "Why is this bad": "It will be more difficult for users to discover the\npurpose of the crate, and key information related to it.", + "Known problems": "None.", + "Example": "```toml\n# This `Cargo.toml` is missing an authors field:\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/Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 {\n x as u64\n}\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 {\n u64::from(x)\n}\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 {\n x as u8\n}\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e., nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX;\nx as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_ref_to_mut", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of `&T` to `&mut T` anywhere in the code.", + "Why is this bad": "It\u2019s basically guaranteed to be undefined behaviour.\n`UnsafeCell` is the only way to obtain aliasable data that is considered\nmutable.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn x(r: &i32) {\n unsafe {\n *(r as *const _ as *mut _) += 1;\n }\n}\n```\n\nInstead consider using interior mutability types.\n\n```rust\nuse std::cell::UnsafeCell;\n\nfn x(r: &UnsafeCell) {\n unsafe {\n *r.get() += 1;\n }\n}\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```ignore\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\", *y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g., `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\n\nif x == NAN { }\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```ignore\nif x == ptr::null {\n ..\n}\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "cognitive_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cognitive complexity.", + "Why is this bad": "Methods of high cognitive complexity tend to be hard to\nboth read and maintain. Also LLVM will tend to optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cognitive-complexity-threshold: u64`: The maximum cognitive complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```ignore\nconst FOO: &'static [(&'static str, &'static str, fn(&Bar) -> bool)] =\n&[...]\n```\nThis code can be rewritten as\n```ignore\n const FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n // `*t` or `&t`'s\n```" + } + }, + { + "id": "dbg_macro", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of dbg!() macro.", + "Why is this bad": "`dbg!` macro is intended as a debugging tool. It\nshould not be in version control.", + "Known problems": "None.", + "Example": "```rust,ignore\n// Bad\ndbg!(true)\n\n// Good\ntrue\n```" + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g., contains a `Cell`, `Mutex`, `AtomicXxxx`, etc.).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g., the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_cfg_attr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.", + "Why is this bad": "Since 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.", + "Known problems": "This 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)", + "Example": "Bad:\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nGood:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else() { /* ... */ }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```text\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```ignore\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n \"CamelCase\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simplified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = 3;\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_bounds", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for generics with `std::ops::Drop` as bounds.", + "Why is this bad": "`Drop` bounds do not really accomplish anything.\nA type may have compiler-generated drop glue without implementing the\n`Drop` trait itself. The `Drop` trait also only has one method,\n`Drop::drop`, and that function is by fiat not callable in user code.\nSo there is really no use case for using `Drop` in trait bounds.\n\nThe most likely use case of a drop bound is to distinguish between types\nthat have destructors and types that don't. Combined with specialization,\na naive coder would write an implementation that assumed a type could be\ntrivially dropped, then write a specialization for `T: Drop` that actually\ncalls the destructor. Except that doing so is not correct; String, for\nexample, doesn't actually implement Drop, but because String contains a\nVec, assuming it can be trivially dropped will leak memory.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {}\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```ignore\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g., MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // We don't care about zero.\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```no_run\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0,\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nif x + 1 == x + 1 {}\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g., `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\nlet x = 1;\n0 / x;\n0 * x;\nx & 0;\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {\n x = 1;\n 1\n} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet v: f32 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789\n\n// Good\nlet v: f64 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```ignore\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```ignore\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() {\n ..\n}\n```\ncan be rewritten to\n```ignore\nfor x in y {\n ..\n}\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```ignore\n// with `y` a `Vec` or slice:\nfor x in y.iter() {\n ..\n}\n```\ncan be rewritten to\n```rust\nfor x in &y {\n ..\n}\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) {\n ..\n}\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nlet x = 1.2331f64;\nlet y = 1.2332f64;\nif y == 1.23f64 { }\nif y != x {} // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE = 1.00f64;\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 { 1 }\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 { 1 }\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 {\n 1\n};\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 {\n 1\n};\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```ignore\nfor (k, _) in &map {\n ..\n}\n```\n\ncould be replaced by\n\n```ignore\nfor k in map.keys() {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in option {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Some(x) = option {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in result {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Ok(x) = result {\n ..\n}\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "Not a replacement for error handling: Using either\n`.unwrap()` or the Index trait (`[]`) carries the risk of causing a `panic`\nif the value being accessed is `None`. If the use of `.get().unwrap()` is a\ntemporary placeholder for dealing with the `Option` type, then this does\nnot mitigate the need for error handling. If there is a chance that `.get()`\nwill be `None` in your program, then it is advisable that the `None` case\nis handled in a future refactor instead of using `.unwrap()` or the Index\ntrait.", + "Example": "```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g., `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```ignore\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```ignore\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nif a == b {\n \u2026\n} else if a == b {\n \u2026\n}\n```\n\nNote that this lint ignores all conditions with a function call as it could\nhave side effects:\n\n```ignore\nif foo() {\n \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { }\n\npub fn foo(map: &mut HashMap) { }\n```" + } + }, + { + "id": "implicit_return", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for missing return statements at the end of a block.", + "Why is this bad": "Actually omitting the return keyword is idiomatic Rust code. Programmers\ncoming from other languages might prefer the expressiveness of `return`. It's possible to miss\nthe last returning statement because the only difference is a missing `;`. Especially in bigger\ncode with multiple return paths having a `return` keyword makes it easier to find the\ncorresponding statements.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: usize) {\n x\n}\n```\nadd return\n```rust\nfn foo(x: usize) {\n return x;\n}\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 618_64_9189_73_511;\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```no_run\nuse std::iter;\n\niter::repeat(1_u8).collect::>();\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```ignore\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "into_iter_on_array", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `into_iter` calls on types which should be replaced by `iter` or\n`iter_mut`.", + "Why is this bad": "Arrays and `PathBuf` do not yet have an `into_iter` method which move out\ntheir content into an iterator. Auto-referencing resolves the `into_iter` call to its reference\ninstead, like `<&[T; N] as IntoIterator>::into_iter`, which just iterates over item references\nlike calling `iter` would. Furthermore, when the standard library actually\n[implements the `into_iter` method][25725] which moves the content out of the array, the\noriginal use of `into_iter` got inferred with the wrong type and the code will be broken.", + "Known problems": "None", + "Example": "```rust\nlet _ = [1, 2, 3].into_iter().map(|x| *x).collect::>();\n```\n\n[25725]: https://github.com/rust-lang/rust/issues/25725" + } + }, + { + "id": "into_iter_on_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `into_iter` calls on references which should be replaced by `iter`\nor `iter_mut`.", + "Why is this bad": "Readability. Calling `into_iter` on a reference will not move out its\ncontent into the resulting iterator, which is confusing. It is better just call `iter` or\n`iter_mut` directly.", + "Known problems": "None", + "Example": "```rust\nlet _ = (&vec![3, 4, 5]).into_iter();\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```no_run\nlet bad_ref: &usize = unsafe { std::mem::zeroed() };\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```ignore\nfor x in y.next() {\n ..\n}\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```ignore\nfor x in (5..5).step_by(0) {\n ..\n}\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 6186491_8973511;\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a enum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n pub fn len(&self) -> usize {\n ..\n }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```ignore\nif x.len() == 0 {\n ..\n}\nif y.len() != 0 {\n ..\n}\n```\ninstead use\n```ignore\nif x.is_empty() {\n ..\n}\nif !y.is_empty() {\n ..\n}\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = {\n 1;\n};\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```ignore\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```ignore\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```ignore\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) {\n m.insert(k.clone(), v);\n}\n```", + "Example": "```rust\nif !m.contains_key(&k) {\n m.insert(k, v)\n}\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\niter.map(|x| x.iter()).flatten()\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1...10 => println!(\"1 ... 10\"),\n 5...15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust,ignore\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x: Result = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_discriminant_non_enum", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `mem::discriminant()` on a non-enum type.", + "Why is this bad": "The value of `mem::discriminant()` on non-enum types\nis unspecified.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nmem::discriminant(&\"hello\");\nmem::discriminant(&&Some(2));\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```ignore\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore, it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_const_for_fn", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Suggests the use of `const` in functions and methods where possible.", + "Why is this bad": "Not having the function const prevents callers of the function from being const as well.", + "Known problems": "Const 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.", + "Example": "```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```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make\nsense. It allows the crate to require all exported methods to be `#[inline]` by default, and\nthen opt out for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32;\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```ignore\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "module_name_repetitions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nlet a = x % 1;\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```ignore\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::sync::atomic::AtomicBool` and `std::sync::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::sync::atomic::AtomicUsize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x {\n false\n} else {\n true\n}\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "None." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\nlet mut v = Vec::::new();\nlet _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```ignore\nlet len = iterator.collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 {\n x\n}\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```ignore\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) -> usize {\n return x;\n}\n```\nsimplify to\n```rust\nfn foo(x: usize) -> usize {\n x\n}\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint {\n x: 1,\n y: 0,\n ..zero_point\n}\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g., `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```ignore\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop {\n ..;\n break;\n}\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).\n\nIt detects both the case when a manual\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\nimplementation is required and also when it can be created with\n`#[derive(Default)]`", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```ignore\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nOr, if\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\ncan be derived by `#[derive(Default)]`:\n\n```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nInstead, use:\n\n```rust\n#[derive(Default)]\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```ignore\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nuse std::fs::OpenOptions;\n\nOpenOptions::new().read(true).truncate(true);\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) {\n println!(\"{}\", unsafe { *x });\n}\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```ignore\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```ignore\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```ignore\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}\n```" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```no_run\n# #![allow(const_err)]\nlet x = [1, 2, 3, 4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```no_run\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```ignore\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.offset(offset as isize);\n}\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.add(offset);\n}\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator.", + "Why is this bad": "Question mark usage is more idiomatic.", + "Known problems": "None", + "Example": "```ignore\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```ignore\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g., `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g., `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e., `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_clone", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for a redudant `clone()` (and its relatives) which clones an owned\nvalue that is going to be dropped without further use.", + "Why is this bad": "It is not always possible for the compiler to eliminate useless\nallocations and deallocations generated by redundant `clone()`s.", + "Known problems": "* Suggestions made by this lint could require NLL to be enabled.\n* False-positive if there is a borrow preventing the value from moving out.\n\n```rust\nlet x = String::new();\n\nlet y = &x;\n\nfoo(x.clone()); // This lint suggests to remove this `clone()`\n```", + "Example": "```rust\n{\n let x = Foo::new();\n call(x.clone());\n call(x.clone()); // this can just pass `x`\n}\n\n[\"lorem\", \"ipsum\"].join(\" \").to_string()\n\nPath::new(\"/a/b\").join(\"c\").to_path_buf()\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee rust-lang/rust-clippy#1439 for more details.", + "Example": "```rust,ignore\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_closure_for_method_calls", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for closures which only invoke a method on the closure\nargument and can be replaced by referencing the method directly.", + "Why is this bad": "It's unnecessary to create the closure.", + "Known problems": "rust-lang/rust-clippy#3071, rust-lang/rust-clippy#4002,\nrust-lang/rust-clippy#3942", + "Example": "```rust,ignore\nSome('a').map(|s| s.to_uppercase());\n```\nmay be rewritten as\n```rust,ignore\nSome('a').map(char::to_uppercase);\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```ignore\nlet foo = Foo { bar };\n```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\n\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```ignore\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```ignore\nfor x in 5..10 - 5 {\n ..\n} // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y;\nlet x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```ignore\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X {\n ..\n }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```ignore\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g., `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => (),\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let else` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "Using `match`:\n\n```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```\n\nUsing `if let` with `else`:\n\n```rust\nif let Some(ref foo) = x {\n bar(foo);\n} else {\n bar(other_ref);\n}\n```" + } + }, + { + "id": "slow_vector_initialization", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks slow zero-filled vector initialization", + "Why is this bad": "These structures are non-idiomatic and less efficient than simply using\n`vec![0; len]`.", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nvec1.resize(len, 0);\n\nlet mut vec2 = Vec::with_capacity(len);\nvec2.extend(repeat(0).take(len))\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore, some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def);\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g., `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else`. It lints if the `else`\nis followed immediately by a newline or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} { // looks like an `else` is missing here\n}\n\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\n{ // this is the `else` block of the previous `if`, but should it be?\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n ..\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "too_many_lines", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions with a large amount of lines.", + "Why is this bad": "Functions with a lot of lines are harder to understand\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.", + "Known problems": "None.", + "Example": "``` rust\nfn im_too_long() {\nprintln!(\"\");\n// ... 100 more LoC\nprintln!(\"\");\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-lines-threshold: u64`: The maximum number of lines a function or method can have (defaults to `100 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g., changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool {\n true\n}\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "Transmutes are dangerous and error-prone, whereas `from_bits` is intuitive\nand safe.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "transmuting_null", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmute calls which would receive a null pointer.", + "Why is this bad": "Transmuting a null pointer is undefined behavior.", + "Known problems": "Not all cases can be detected at the moment of this writing.\nFor example, variables which hold a null pointer and are then fed to a `transmute`\ncall, aren't detectable yet.", + "Example": "```rust\nlet null_ref: &u64 = unsafe { std::mem::transmute(0 as *const u64) };\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```no_run\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a\nunit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif {\n foo();\n} == {\n bar();\n} {\n baz();\n}\n```\nis equal to\n```rust\n{\n foo();\n bar();\n baz();\n}\n```" + } + }, + { + "id": "unknown_clippy_lints", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `allow`/`warn`/`deny`/`forbid` attributes with scoped clippy\nlints and if those lints exist in clippy. If there is a uppercase letter in the lint name\n(not the tool name) and a lowercase version of this lint exists, it will suggest to lowercase\nthe lint name.", + "Why is this bad": "A lint attribute with a mistyped lint name won't have an effect.", + "Known problems": "None.", + "Example": "Bad:\n```rust\n#![warn(if_not_els)]\n#![deny(clippy::All)]\n```\n\nGood:\n```rust\n#![warn(if_not_else)]\n#![deny(clippy::all)]\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```ignore\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```ignore\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 61864918973511;\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unsafe_vector_initialization", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```ignore\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g., the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () {\n ()\n}\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "- False positive when using associated types (#2843)\n- False positives in some situations when using generics (#3410)", + "Example": "```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```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```ignore\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"foo\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "vec_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Vec>` where T: Sized anywhere in the code.", + "Why is this bad": "`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.", + "Known problems": "Vec> makes sense if T is a large type (see #3530,\n1st comment).", + "Example": "```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nif x & 0x1111 == 0 { }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```ignore\nwhile let Some(val) = iter() {\n ..\n}\n```" + } + }, + { + "id": "wildcard_dependencies", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard dependencies in the `Cargo.toml`.", + "Why is this bad": "[As the edition guide says](https://rust-lang-nursery.github.io/edition-guide/rust-2018/cargo-and-crates-io/crates-io-disallows-wildcard-dependencies.html),\nit is highly unlikely that you work with any possible version of your dependency,\nand wildcard dependencies would cause unnecessary breakage in the ecosystem.", + "Known problems": "None.", + "Example": "```toml\n[dependencies]\nregex = \"*\"\n```" + } + }, + { + "id": "wildcard_enum_match_arm", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard enum matches using `_`.", + "Why is this bad": "New enum variants added by library updates can be missed.", + "Known problems": "Suggested replacements may be incorrect if guards exhaustively cover some\nvariants, and also may not use correct path to enum if it's not present in the current scope.", + "Example": "```rust\nmatch x {\n A => {},\n _ => {},\n}\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(buf, \"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```ignore\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\nlet a = 0 as *const u32;\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.36.0/index.html b/rust-1.36.0/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.36.0/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.36.0/lints.json b/rust-1.36.0/lints.json new file mode 100644 index 000000000000..c566ba0eb210 --- /dev/null +++ b/rust-1.36.0/lints.json @@ -0,0 +1,3397 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat is is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g., 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nlet vec: Vec = vec![];\nif vec.len() <= 0 {}\nif 100 > std::i32::MAX {}\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "None.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assertions_on_constants", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `assert!(true)` and `assert!(false)` calls.", + "Why is this bad": "Will be optimized out by the compiler or should probably be replaced by a\npanic!() or unreachable!()", + "Known problems": "None", + "Example": "```rust,ignore\nassert!(false)\n// or\nassert!(true)\n// or\nconst B: bool = false;\nassert!(B)\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\nlet b = 0;\n// ...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } { /* ... */ }\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```ignore\nif { let x = somefunc(); x } {}\n// or\nif somefunc(|x| { x == 47 }) {}\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true`,\n`x != true` and order comparisons such as `x < true` (or vice versa) and\nsuggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true {} // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.,\ncontains a `Cell`, `Mutex`, `AtomicXxxx`, etc.) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust,ignore\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust,ignore\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust,ignore\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cargo_common_metadata", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks 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", + "Why is this bad": "It will be more difficult for users to discover the\npurpose of the crate, and key information related to it.", + "Known problems": "None.", + "Example": "```toml\n# This `Cargo.toml` is missing an authors field:\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/Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 {\n x as u64\n}\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 {\n u64::from(x)\n}\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 {\n x as u8\n}\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e., nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX;\nx as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_ref_to_mut", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of `&T` to `&mut T` anywhere in the code.", + "Why is this bad": "It\u2019s basically guaranteed to be undefined behaviour.\n`UnsafeCell` is the only way to obtain aliasable data that is considered\nmutable.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn x(r: &i32) {\n unsafe {\n *(r as *const _ as *mut _) += 1;\n }\n}\n```\n\nInstead consider using interior mutability types.\n\n```rust\nuse std::cell::UnsafeCell;\n\nfn x(r: &UnsafeCell) {\n unsafe {\n *r.get() += 1;\n }\n}\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```ignore\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\", *y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g., `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\n\nif x == NAN { }\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```ignore\nif x == ptr::null {\n ..\n}\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "cognitive_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cognitive complexity.", + "Why is this bad": "Methods of high cognitive complexity tend to be hard to\nboth read and maintain. Also LLVM will tend to optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cognitive-complexity-threshold: u64`: The maximum cognitive complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "const_static_lifetime", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```ignore\nconst FOO: &'static [(&'static str, &'static str, fn(&Bar) -> bool)] =\n&[...]\n```\nThis code can be rewritten as\n```ignore\n const FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n // `*t` or `&t`'s\n```" + } + }, + { + "id": "dbg_macro", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of dbg!() macro.", + "Why is this bad": "`dbg!` macro is intended as a debugging tool. It\nshould not be in version control.", + "Known problems": "None.", + "Example": "```rust,ignore\n// Bad\ndbg!(true)\n\n// Good\ntrue\n```" + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g., contains a `Cell`, `Mutex`, `AtomicXxxx`, etc.).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g., the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_cfg_attr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.", + "Why is this bad": "Since 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.", + "Known problems": "This 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)", + "Example": "Bad:\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nGood:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else() { /* ... */ }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```text\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```ignore\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n \"CamelCase\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparions that could be simplified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = 3;\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_bounds", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for generics with `std::ops::Drop` as bounds.", + "Why is this bad": "`Drop` bounds do not really accomplish anything.\nA type may have compiler-generated drop glue without implementing the\n`Drop` trait itself. The `Drop` trait also only has one method,\n`Drop::drop`, and that function is by fiat not callable in user code.\nSo there is really no use case for using `Drop` in trait bounds.\n\nThe most likely use case of a drop bound is to distinguish between types\nthat have destructors and types that don't. Combined with specialization,\na naive coder would write an implementation that assumed a type could be\ntrivially dropped, then write a specialization for `T: Drop` that actually\ncalls the destructor. Except that doing so is not correct; String, for\nexample, doesn't actually implement Drop, but because String contains a\nVec, assuming it can be trivially dropped will leak memory.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {}\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```ignore\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g., MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // We don't care about zero.\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```no_run\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0,\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nif x + 1 == x + 1 {}\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g., `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\nlet x = 1;\n0 / x;\n0 * x;\nx & 0;\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {\n x = 1;\n 1\n} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet v: f32 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789\n\n// Good\nlet v: f64 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantics of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```ignore\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```ignore\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() {\n ..\n}\n```\ncan be rewritten to\n```ignore\nfor x in y {\n ..\n}\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```ignore\n// with `y` a `Vec` or slice:\nfor x in y.iter() {\n ..\n}\n```\ncan be rewritten to\n```rust\nfor x in &y {\n ..\n}\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) {\n ..\n}\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_map_next", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter_map(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "find_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.find(_).map(_)`.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\n (0..3).find(|x| x == 2).map(|x| x * 2);\n```\nCan be written as\n```rust\n (0..3).find_map(|x| if x == 2 { Some(x * 2) } else { None });\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nlet x = 1.2331f64;\nlet y = 1.2332f64;\nif y == 1.23f64 { }\nif y != x {} // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE = 1.00f64;\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 { 1 }\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 { 1 }\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 {\n 1\n};\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 {\n 1\n};\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```ignore\nfor (k, _) in &map {\n ..\n}\n```\n\ncould be replaced by\n\n```ignore\nfor k in map.keys() {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in option {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Some(x) = option {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in result {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Ok(x) = result {\n ..\n}\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_unwrap", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "Not a replacement for error handling: Using either\n`.unwrap()` or the Index trait (`[]`) carries the risk of causing a `panic`\nif the value being accessed is `None`. If the use of `.get().unwrap()` is a\ntemporary placeholder for dealing with the `Option` type, then this does\nnot mitigate the need for error handling. If there is a chance that `.get()`\nwill be `None` in your program, then it is advisable that the `None` case\nis handled in a future refactor instead of using `.unwrap()` or the Index\ntrait.", + "Example": "```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g., `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```ignore\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```ignore\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nif a == b {\n \u2026\n} else if a == b {\n \u2026\n}\n```\n\nNote that this lint ignores all conditions with a function call as it could\nhave side effects:\n\n```ignore\nif foo() {\n \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { }\n\npub fn foo(map: &mut HashMap) { }\n```" + } + }, + { + "id": "implicit_return", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for missing return statements at the end of a block.", + "Why is this bad": "Actually omitting the return keyword is idiomatic Rust code. Programmers\ncoming from other languages might prefer the expressiveness of `return`. It's possible to miss\nthe last returning statement because the only difference is a missing `;`. Especially in bigger\ncode with multiple return paths having a `return` keyword makes it easier to find the\ncorresponding statements.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: usize) {\n x\n}\n```\nadd return\n```rust\nfn foo(x: usize) {\n return x;\n}\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 618_64_9189_73_511;\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of indexing or slicing. Arrays are special cased, 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```no_run\nuse std::iter;\n\niter::repeat(1_u8).collect::>();\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```ignore\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "into_iter_on_array", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `into_iter` calls on types which should be replaced by `iter` or\n`iter_mut`.", + "Why is this bad": "Arrays and `PathBuf` do not yet have an `into_iter` method which move out\ntheir content into an iterator. Auto-referencing resolves the `into_iter` call to its reference\ninstead, like `<&[T; N] as IntoIterator>::into_iter`, which just iterates over item references\nlike calling `iter` would. Furthermore, when the standard library actually\n[implements the `into_iter` method](https://github.com/rust-lang/rust/issues/25725) which moves\nthe content out of the array, the original use of `into_iter` got inferred with the wrong type\nand the code will be broken.", + "Known problems": "None", + "Example": "```rust\nlet _ = [1, 2, 3].into_iter().map(|x| *x).collect::>();\n```" + } + }, + { + "id": "into_iter_on_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `into_iter` calls on references which should be replaced by `iter`\nor `iter_mut`.", + "Why is this bad": "Readability. Calling `into_iter` on a reference will not move out its\ncontent into the resulting iterator, which is confusing. It is better just call `iter` or\n`iter_mut` directly.", + "Known problems": "None", + "Example": "```rust\nlet _ = (&vec![3, 4, 5]).into_iter();\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```no_run\nlet bad_ref: &usize = unsafe { std::mem::zeroed() };\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```ignore\nfor x in y.next() {\n ..\n}\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```ignore\nfor x in (5..5).step_by(0) {\n ..\n}\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 6186491_8973511;\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a enum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n pub fn len(&self) -> usize {\n ..\n }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```ignore\nif x.len() == 0 {\n ..\n}\nif y.len() != 0 {\n ..\n}\n```\ninstead use\n```ignore\nif x.is_empty() {\n ..\n}\nif !y.is_empty() {\n ..\n}\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = {\n 1;\n};\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```ignore\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```ignore\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```ignore\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) {\n m.insert(k.clone(), v);\n}\n```", + "Example": "```rust\nif !m.contains_key(&k) {\n m.insert(k, v)\n}\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\niter.map(|x| x.iter()).flatten()\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1...10 => println!(\"1 ... 10\"),\n 5...15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust,ignore\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x: Result = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_discriminant_non_enum", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `mem::discriminant()` on a non-enum type.", + "Why is this bad": "The value of `mem::discriminant()` on non-enum types\nis unspecified.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nmem::discriminant(&\"hello\");\nmem::discriminant(&&Some(2));\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```ignore\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore, it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_const_for_fn", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Suggests the use of `const` in functions and methods where possible.", + "Why is this bad": "Not having the function const prevents callers of the function from being const as well.", + "Known problems": "Const 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.", + "Example": "```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```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make\nsense. It allows the crate to require all exported methods to be `#[inline]` by default, and\nthen opt out for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32;\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```ignore\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "module_name_repetitions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nlet a = x % 1;\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```ignore\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::sync::atomic::AtomicBool` and `std::sync::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::sync::atomic::AtomicUsize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we of course do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x {\n false\n} else {\n true\n}\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "None." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\nlet mut v = Vec::::new();\nlet _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```ignore\nlet len = iterator.collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 {\n x\n}\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```ignore\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) -> usize {\n return x;\n}\n```\nsimplify to\n```rust\nfn foo(x: usize) -> usize {\n x\n}\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint {\n x: 1,\n y: 0,\n ..zero_point\n}\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g., `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```ignore\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop {\n ..;\n break;\n}\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).\n\nIt detects both the case when a manual\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\nimplementation is required and also when it can be created with\n`#[derive(Default)]`", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```ignore\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nOr, if\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\ncan be derived by `#[derive(Default)]`:\n\n```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nInstead, use:\n\n```rust\n#[derive(Default)]\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"H\u00e4?\"\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```ignore\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nuse std::fs::OpenOptions;\n\nOpenOptions::new().read(true).truncate(true);\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereferences raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) {\n println!(\"{}\", unsafe { *x });\n}\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```ignore\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```ignore\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```ignore\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}\n```" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```no_run\n# #![allow(const_err)]\nlet x = [1, 2, 3, 4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```no_run\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "path_buf_push_overwrite", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "* Checks for [push](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.push)\ncalls on `PathBuf` that can cause overwrites.", + "Why is this bad": "Calling `push` with a root path at the start can overwrite the\nprevious defined path.", + "Known problems": "None.", + "Example": "```rust\nuse std::path::PathBuf;\n\nlet mut x = PathBuf::from(\"/foo\");\nx.push(\"/bar\");\nassert_eq!(x, PathBuf::from(\"/bar\"));\n```\nCould be written:\n\n```rust\nuse std::path::PathBuf;\n\nlet mut x = PathBuf::from(\"/foo\");\nx.push(\"bar\");\nassert_eq!(x, PathBuf::from(\"/foo/bar\"));\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```ignore\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.offset(offset as isize);\n}\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.add(offset);\n}\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator.", + "Why is this bad": "Question mark usage is more idiomatic.", + "Known problems": "None", + "Example": "```ignore\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```ignore\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g., `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g., `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e., `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_clone", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for a redudant `clone()` (and its relatives) which clones an owned\nvalue that is going to be dropped without further use.", + "Why is this bad": "It is not always possible for the compiler to eliminate useless\nallocations and deallocations generated by redundant `clone()`s.", + "Known problems": "* Suggestions made by this lint could require NLL to be enabled.\n* False-positive if there is a borrow preventing the value from moving out.\n\n```rust\nlet x = String::new();\n\nlet y = &x;\n\nfoo(x.clone()); // This lint suggests to remove this `clone()`\n```", + "Example": "```rust\n{\n let x = Foo::new();\n call(x.clone());\n call(x.clone()); // this can just pass `x`\n}\n\n[\"lorem\", \"ipsum\"].join(\" \").to_string()\n\nPath::new(\"/a/b\").join(\"c\").to_path_buf()\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee rust-lang/rust-clippy#1439 for more details.", + "Example": "```rust,ignore\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_closure_for_method_calls", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for closures which only invoke a method on the closure\nargument and can be replaced by referencing the method directly.", + "Why is this bad": "It's unnecessary to create the closure.", + "Known problems": "rust-lang/rust-clippy#3071, rust-lang/rust-clippy#4002,\nrust-lang/rust-clippy#3942", + "Example": "```rust,ignore\nSome('a').map(|s| s.to_uppercase());\n```\nmay be rewritten as\n```rust,ignore\nSome('a').map(char::to_uppercase);\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```ignore\nlet foo = Foo { bar };\n```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\n\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```ignore\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```ignore\nfor x in 5..10 - 5 {\n ..\n} // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y;\nlet x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```ignore\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X {\n ..\n }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```ignore\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g., `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => (),\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let else` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "Using `match`:\n\n```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```\n\nUsing `if let` with `else`:\n\n```rust\nif let Some(ref foo) = x {\n bar(foo);\n} else {\n bar(other_ref);\n}\n```" + } + }, + { + "id": "slow_vector_initialization", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks slow zero-filled vector initialization", + "Why is this bad": "These structures are non-idiomatic and less efficient than simply using\n`vec![0; len]`.", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nvec1.resize(len, 0);\n\nlet mut vec2 = Vec::with_capacity(len);\nvec2.extend(repeat(0).take(len))\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore, some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def);\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g., `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else`. It lints if the `else`\nis followed immediately by a newline or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} { // looks like an `else` is missing here\n}\n\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\n{ // this is the `else` block of the previous `if`, but should it be?\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n ..\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "too_many_lines", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions with a large amount of lines.", + "Why is this bad": "Functions with a lot of lines are harder to understand\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.", + "Known problems": "None.", + "Example": "``` rust\nfn im_too_long() {\nprintln!(\"\");\n// ... 100 more LoC\nprintln!(\"\");\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-lines-threshold: u64`: The maximum number of lines a function or method can have (defaults to `100 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g., changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool {\n true\n}\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "Transmutes are dangerous and error-prone, whereas `from_bits` is intuitive\nand safe.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "transmuting_null", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmute calls which would receive a null pointer.", + "Why is this bad": "Transmuting a null pointer is undefined behavior.", + "Known problems": "Not all cases can be detected at the moment of this writing.\nFor example, variables which hold a null pointer and are then fed to a `transmute`\ncall, aren't detectable yet.", + "Example": "```rust\nlet null_ref: &u64 = unsafe { std::mem::transmute(0 as *const u64) };\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```no_run\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a\nunit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif {\n foo();\n} == {\n bar();\n} {\n baz();\n}\n```\nis equal to\n```rust\n{\n foo();\n bar();\n baz();\n}\n```" + } + }, + { + "id": "unknown_clippy_lints", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `allow`/`warn`/`deny`/`forbid` attributes with scoped clippy\nlints and if those lints exist in clippy. If there is a uppercase letter in the lint name\n(not the tool name) and a lowercase version of this lint exists, it will suggest to lowercase\nthe lint name.", + "Why is this bad": "A lint attribute with a mistyped lint name won't have an effect.", + "Known problems": "None.", + "Example": "Bad:\n```rust\n#![warn(if_not_els)]\n#![deny(clippy::All)]\n```\n\nGood:\n```rust\n#![warn(if_not_else)]\n#![deny(clippy::all)]\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```ignore\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```ignore\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 61864918973511;\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unsafe_vector_initialization", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```ignore\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g., the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () {\n ()\n}\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "- False positive when using associated types (#2843)\n- False positives in some situations when using generics (#3410)", + "Example": "```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```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]` and `#[allow(deprecated)]` on\n`use` items and `#[allow(unused_imports)]` on `extern crate` items with a\n`#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```ignore\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"foo\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "vec_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Vec>` where T: Sized anywhere in the code.", + "Why is this bad": "`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.", + "Known problems": "Vec> makes sense if T is a large type (see #3530,\n1st comment).", + "Example": "```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nif x & 0x1111 == 0 { }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```ignore\nwhile let Some(val) = iter() {\n ..\n}\n```" + } + }, + { + "id": "wildcard_dependencies", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard dependencies in the `Cargo.toml`.", + "Why is this bad": "[As the edition guide says](https://rust-lang-nursery.github.io/edition-guide/rust-2018/cargo-and-crates-io/crates-io-disallows-wildcard-dependencies.html),\nit is highly unlikely that you work with any possible version of your dependency,\nand wildcard dependencies would cause unnecessary breakage in the ecosystem.", + "Known problems": "None.", + "Example": "```toml\n[dependencies]\nregex = \"*\"\n```" + } + }, + { + "id": "wildcard_enum_match_arm", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard enum matches using `_`.", + "Why is this bad": "New enum variants added by library updates can be missed.", + "Known problems": "Suggested replacements may be incorrect if guards exhaustively cover some\nvariants, and also may not use correct path to enum if it's not present in the current scope.", + "Example": "```rust\nmatch x {\n A => {},\n _ => {},\n}\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(buf, \"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```ignore\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\nlet a = 0 as *const u32;\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.37.0/index.html b/rust-1.37.0/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.37.0/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.37.0/lints.json b/rust-1.37.0/lints.json new file mode 100644 index 000000000000..76adcc565940 --- /dev/null +++ b/rust-1.37.0/lints.json @@ -0,0 +1,3430 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat it is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g., 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nlet vec: Vec = vec![];\nif vec.len() <= 0 {}\nif 100 > std::i32::MAX {}\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "None.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assertions_on_constants", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `assert!(true)` and `assert!(false)` calls.", + "Why is this bad": "Will be optimized out by the compiler or should probably be replaced by a\npanic!() or unreachable!()", + "Known problems": "None", + "Example": "```rust,ignore\nassert!(false)\n// or\nassert!(true)\n// or\nconst B: bool = false;\nassert!(B)\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\nlet b = 0;\n// ...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } { /* ... */ }\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```ignore\nif { let x = somefunc(); x } {}\n// or\nif somefunc(|x| { x == 47 }) {}\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true`,\n`x != true` and order comparisons such as `x < true` (or vice versa) and\nsuggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust\nif x == true {} // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.,\ncontains a `Cell`, `Mutex`, `AtomicXxxx`, etc.) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust,ignore\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust,ignore\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust,ignore\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = Box::new(1);\n foo(*x);\n println!(\"{}\", *x);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cargo_common_metadata", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks 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", + "Why is this bad": "It will be more difficult for users to discover the\npurpose of the crate, and key information related to it.", + "Known problems": "None.", + "Example": "```toml\n# This `Cargo.toml` is missing an authors field:\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/Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for on casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 {\n x as u64\n}\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 {\n u64::from(x)\n}\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for on casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 {\n x as u8\n}\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e., nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nu32::MAX as i32 // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = u64::MAX;\nx as f64\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "None.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_ref_to_mut", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of `&T` to `&mut T` anywhere in the code.", + "Why is this bad": "It\u2019s basically guaranteed to be undefined behaviour.\n`UnsafeCell` is the only way to obtain aliasable data that is considered\nmutable.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn x(r: &i32) {\n unsafe {\n *(r as *const _ as *mut _) += 1;\n }\n}\n```\n\nInstead consider using interior mutability types.\n\n```rust\nuse std::cell::UnsafeCell;\n\nfn x(r: &UnsafeCell) {\n unsafe {\n *r.get() += 1;\n }\n}\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128 // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```ignore\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nname.chars().next() == Some('_')\n```" + } + }, + { + "id": "checked_conversions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit bounds checking when casting.", + "Why is this bad": "Reduces the readability of statements & is error prone.", + "Known problems": "None.", + "Example": "```rust\nfoo <= i32::max_value() as u32\n```\n\nCould be written:\n\n```rust\ni32::try_from(foo).is_ok()\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\", *y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone()\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g., `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nx.clone()\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\n\nif x == NAN { }\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```ignore\nif x == ptr::null {\n ..\n}\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nx.to_owned() == y\n```" + } + }, + { + "id": "cognitive_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cognitive complexity.", + "Why is this bad": "Methods of high cognitive complexity tend to be hard to\nboth read and maintain. Also LLVM will tend to optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cognitive-complexity-threshold: u64`: The maximum cognitive complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as\n // `*t` or `&t`'s\n```" + } + }, + { + "id": "dbg_macro", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of dbg!() macro.", + "Why is this bad": "`dbg!` macro is intended as a debugging tool. It\nshould not be in version control.", + "Known problems": "None.", + "Example": "```rust,ignore\n// Bad\ndbg!(true)\n\n// Good\ntrue\n```" + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g., contains a `Cell`, `Mutex`, `AtomicXxxx`, etc.).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g., the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_cfg_attr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.", + "Why is this bad": "Since 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.", + "Known problems": "This 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)", + "Example": "Bad:\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nGood:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else() { /* ... */ }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```text\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```ignore\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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) { .. }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n \"CamelCase\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparisons that could be simplified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nx == y || x < y\n```\n\nCould be written as:\n\n```rust\nx <= y\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = 3;\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0))\nfoo((0))\n((1, 2))\n```" + } + }, + { + "id": "drop_bounds", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for generics with `std::ops::Drop` as bounds.", + "Why is this bad": "`Drop` bounds do not really accomplish anything.\nA type may have compiler-generated drop glue without implementing the\n`Drop` trait itself. The `Drop` trait also only has one method,\n`Drop::drop`, and that function is by fiat not callable in user code.\nSo there is really no use case for using `Drop` in trait bounds.\n\nThe most likely use case of a drop bound is to distinguish between types\nthat have destructors and types that don't. Combined with specialization,\na naive coder would write an implementation that assumed a type could be\ntrivially dropped, then write a specialization for `T: Drop` that actually\ncalls the destructor. Except that doing so is not correct; String, for\nexample, doesn't actually implement Drop, but because String contains a\nVec, assuming it can be trivially dropped will leak memory.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {}\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```ignore\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g., MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // We don't care about zero.\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code(..) { ... }\n\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine(..) { ... }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too(..) { ... }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```no_run\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0,\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nif x + 1 == x + 1 {}\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g., `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\nlet x = 1;\n0 / x;\n0 * x;\nx & 0;\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {\n x = 1;\n 1\n} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet v: f32 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789\n\n// Good\nlet v: f64 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantics of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg))\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|_| panic!(\"Err {}: {}\", err_code, err_msg))\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```ignore\nfor i in 0..v.len() { foo(v[i]);\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```ignore\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() {\n ..\n}\n```\ncan be rewritten to\n```ignore\nfor x in y {\n ..\n}\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```ignore\n// with `y` a `Vec` or slice:\nfor x in y.iter() {\n ..\n}\n```\ncan be rewritten to\n```rust\nfor x in &y {\n ..\n}\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) {\n ..\n}\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\niter.filter(|x| x == 0).map(|x| x * 2)\n```" + } + }, + { + "id": "filter_map_next", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter_map(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.filter(|x| x == 0).next()\n```" + } + }, + { + "id": "find_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.find(_).map(_)`.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\n (0..3).find(|x| x == 2).map(|x| x * 2);\n```\nCan be written as\n```rust\n (0..3).find_map(|x| if x == 2 { Some(x * 2) } else { None });\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nlet x = 1.2331f64;\nlet y = 1.2332f64;\nif y == 1.23f64 { }\nif y != x {} // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nconst ONE = 1.00f64;\nx == ONE // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 { 1 }\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 { 1 }\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 {\n 1\n};\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 {\n 1\n};\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```ignore\nfor (k, _) in &map {\n ..\n}\n```\n\ncould be replaced by\n\n```ignore\nfor k in map.keys() {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in option {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Some(x) = option {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in result {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Ok(x) = result {\n ..\n}\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_last_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for using `x.get(x.len() - 1)` instead of\n`x.last()`.", + "Why is this bad": "Using `x.last()` is easier to read and has the same\nresult.\n\nNote that using `x[x.len() - 1]` is semantically different from\n`x.last()`. Indexing into the array will panic on out-of-bounds\naccesses, while `x.get()` and `x.last()` will return `None`.\n\nThere is another lint (get_unwrap) that covers the case of using\n`x.get(index).unwrap()` instead of `x[index]`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet x = vec![2, 3, 5];\nlet last_element = x.get(x.len() - 1);\n\n// Good\nlet x = vec![2, 3, 5];\nlet last_element = x.last();\n```" + } + }, + { + "id": "get_unwrap", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "Not a replacement for error handling: Using either\n`.unwrap()` or the Index trait (`[]`) carries the risk of causing a `panic`\nif the value being accessed is `None`. If the use of `.get().unwrap()` is a\ntemporary placeholder for dealing with the `Option` type, then this does\nnot mitigate the need for error handling. If there is a chance that `.get()`\nwill be `None` in your program, then it is advisable that the `None` case\nis handled in a future refactor instead of using `.unwrap()` or the Index\ntrait.", + "Example": "```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g., `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```ignore\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```ignore\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nif a == b {\n \u2026\n} else if a == b {\n \u2026\n}\n```\n\nNote that this lint ignores all conditions with a function call as it could\nhave side effects:\n\n```ignore\nif foo() {\n \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { }\n\npub fn foo(map: &mut HashMap) { }\n```" + } + }, + { + "id": "implicit_return", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for missing return statements at the end of a block.", + "Why is this bad": "Actually omitting the return keyword is idiomatic Rust code. Programmers\ncoming from other languages might prefer the expressiveness of `return`. It's possible to miss\nthe last returning statement because the only difference is a missing `;`. Especially in bigger\ncode with multiple return paths having a `return` keyword makes it easier to find the\ncorresponding statements.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: usize) -> usize {\n x\n}\n```\nadd return\n```rust\nfn foo(x: usize) -> usize {\n return x;\n}\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 618_64_9189_73_511;\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```no_run\nuse std::iter;\n\niter::repeat(1_u8).collect::>();\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```ignore\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nx >= y + 1\n```\n\nCould be written:\n\n```rust\nx > y\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1\n```" + } + }, + { + "id": "integer_division", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for division of integers", + "Why is this bad": "When outside of some very specific algorithms,\ninteger division is very often a mistake because it discards the\nremainder.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = 3 / 2;\n println!(\"{}\", x);\n}\n```" + } + }, + { + "id": "into_iter_on_array", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `into_iter` calls on types which should be replaced by `iter` or\n`iter_mut`.", + "Why is this bad": "Arrays and `PathBuf` do not yet have an `into_iter` method which move out\ntheir content into an iterator. Auto-referencing resolves the `into_iter` call to its reference\ninstead, like `<&[T; N] as IntoIterator>::into_iter`, which just iterates over item references\nlike calling `iter` would. Furthermore, when the standard library actually\n[implements the `into_iter` method](https://github.com/rust-lang/rust/issues/25725) which moves\nthe content out of the array, the original use of `into_iter` got inferred with the wrong type\nand the code will be broken.", + "Known problems": "None", + "Example": "```rust\nlet _ = [1, 2, 3].into_iter().map(|x| *x).collect::>();\n```" + } + }, + { + "id": "into_iter_on_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `into_iter` calls on references which should be replaced by `iter`\nor `iter_mut`.", + "Why is this bad": "Readability. Calling `into_iter` on a reference will not move out its\ncontent into the resulting iterator, which is confusing. It is better just call `iter` or\n`iter_mut` directly.", + "Known problems": "None", + "Example": "```rust\nlet _ = (&vec![3, 4, 5]).into_iter();\n```" + } + }, + { + "id": "invalid_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for creation of references to zeroed or uninitialized memory.", + "Why is this bad": "Creation of null references is undefined behavior.", + "Known problems": "None.", + "Example": "```no_run\nlet bad_ref: &usize = unsafe { std::mem::zeroed() };\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang/rust-clippy/issues/886", + "Example": "```rust\nlet x : u8 = ...; (x as u32) > 300\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```ignore\nfor x in y.next() {\n ..\n}\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```ignore\nfor x in (5..5).step_by(0) {\n ..\n}\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 6186491_8973511;\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a enum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n pub fn len(&self) -> usize {\n ..\n }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```ignore\nif x.len() == 0 {\n ..\n}\nif y.len() != 0 {\n ..\n}\n```\ninstead use\n```ignore\nif x.is_empty() {\n ..\n}\nif !y.is_empty() {\n ..\n}\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = {\n 1;\n};\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```ignore\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```ignore\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```ignore\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nlet k = &key;\nif !m.contains_key(k) {\n m.insert(k.clone(), v);\n}\n```", + "Example": "```rust\nif !m.contains_key(&k) {\n m.insert(k, v)\n}\n```\ncan be rewritten as:\n```rust\nm.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\niter.map(|x| x.iter()).flatten()\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1...10 => println!(\"1 ... 10\"),\n 5...15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust,ignore\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x: Result = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\n[0..].iter().zip(infinite_iter.take_while(|x| x > 5))\n```" + } + }, + { + "id": "mem_discriminant_non_enum", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `mem::discriminant()` on a non-enum type.", + "Why is this bad": "The value of `mem::discriminant()` on non-enum types\nis unspecified.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nmem::discriminant(&\"hello\");\nmem::discriminant(&&Some(2));\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```ignore\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore, it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\n...\na += a + b;\n```" + } + }, + { + "id": "missing_const_for_fn", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Suggests the use of `const` in functions and methods where possible.", + "Why is this bad": "Not having the function const prevents callers of the function from being const as well.", + "Known problems": "Const 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.", + "Example": "```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```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make\nsense. It allows the crate to require all exported methods to be `#[inline]` by default, and\nthen opt out for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn priv() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn priv() {} // ok\n pub not_ptriv() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32;\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```ignore\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "module_name_repetitions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nlet a = x % 1;\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```ignore\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::sync::atomic::AtomicBool` and `std::sync::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::sync::atomic::AtomicUsize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&my_data.filter(|&x| x == 0u8).count() // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we, of course, do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust\nif x {\n false\n} else {\n true\n}\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "None." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n(&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime\nmismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\nlet mut v = Vec::::new();\nlet _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```ignore\nlet len = iterator.collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 {\n x\n}\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nlet vec = vec!['a', 'b', 'c'];\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```\nCould be written as:\n```rust\nlet vec = vec!['a', 'b', 'c'];\nfor i in vec {\n println!(\"{}\", i);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) -> usize {\n return x;\n}\n```\nsimplify to\n```rust\nfn foo(x: usize) -> usize {\n x\n}\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint {\n x: 1,\n y: 0,\n ..zero_point\n}\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g., `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```ignore\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop {\n ..;\n break;\n}\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).\n\nIt detects both the case when a manual\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\nimplementation is required and also when it can be created with\n`#[derive(Default)]`", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```ignore\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nOr, if\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\ncan be derived by `#[derive(Default)]`:\n\n```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nInstead, use:\n\n```rust\n#[derive(Default)]\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = String::from(\"\u20ac\");\n```\nCould be written as:\n```rust\nlet x = String::from(\"\\u{20ac}\");\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```ignore\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nuse std::fs::OpenOptions;\n\nOpenOptions::new().read(true).truncate(true);\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereference raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) {\n println!(\"{}\", unsafe { *x });\n}\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```ignore\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```ignore\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```ignore\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<&str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option<&str> = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg)\n}\nif let Some(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0)\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}\n```" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new())\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new)\n```\nor\n```rust\nfoo.unwrap_or_default()\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```no_run\n# #![allow(const_err)]\nlet x = [1, 2, 3, 4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```no_run\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { ... }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "path_buf_push_overwrite", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "* Checks for [push](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.push)\ncalls on `PathBuf` that can cause overwrites.", + "Why is this bad": "Calling `push` with a root path at the start can overwrite the\nprevious defined path.", + "Known problems": "None.", + "Example": "```rust\nuse std::path::PathBuf;\n\nlet mut x = PathBuf::from(\"/foo\");\nx.push(\"/bar\");\nassert_eq!(x, PathBuf::from(\"/bar\"));\n```\nCould be written:\n\n```rust\nuse std::path::PathBuf;\n\nlet mut x = PathBuf::from(\"/foo\");\nx.push(\"bar\");\nassert_eq!(x, PathBuf::from(\"/foo/bar\"));\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```ignore\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.offset(offset as isize);\n}\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.add(offset);\n}\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator.", + "Why is this bad": "Question mark usage is more idiomatic.", + "Known problems": "None", + "Example": "```ignore\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```ignore\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g., `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g., `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e., `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len())\n```" + } + }, + { + "id": "redundant_clone", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for a redudant `clone()` (and its relatives) which clones an owned\nvalue that is going to be dropped without further use.", + "Why is this bad": "It is not always possible for the compiler to eliminate useless\nallocations and deallocations generated by redundant `clone()`s.", + "Known problems": "* Suggestions made by this lint could require NLL to be enabled.\n* False-positive if there is a borrow preventing the value from moving out.\n\n```rust\nlet x = String::new();\n\nlet y = &x;\n\nfoo(x.clone()); // This lint suggests to remove this `clone()`\n```", + "Example": "```rust\n{\n let x = Foo::new();\n call(x.clone());\n call(x.clone()); // this can just pass `x`\n}\n\n[\"lorem\", \"ipsum\"].join(\" \").to_string()\n\nPath::new(\"/a/b\").join(\"c\").to_path_buf()\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee rust-lang/rust-clippy#1439 for more details.", + "Example": "```rust,ignore\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust\n(|| 42)()\n```" + } + }, + { + "id": "redundant_closure_for_method_calls", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for closures which only invoke a method on the closure\nargument and can be replaced by referencing the method directly.", + "Why is this bad": "It's unnecessary to create the closure.", + "Known problems": "rust-lang/rust-clippy#3071, rust-lang/rust-clippy#4002,\nrust-lang/rust-clippy#3942", + "Example": "```rust,ignore\nSome('a').map(|s| s.to_uppercase());\n```\nmay be rewritten as\n```rust,ignore\nSome('a').map(char::to_uppercase);\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```ignore\nlet foo = Foo { bar };\n```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\n\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "redundant_static_lifetimes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants and statics with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```ignore\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```ignore\n const FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n static FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Foo(30, 20);\nlet x = (&point).x;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```ignore\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result<&str, &str> = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)))\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result<&str, &str> = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg)\n}\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg))\n}\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function)\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "```rust\nx.unwrap()\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```ignore\nfor x in 5..10 - 5 {\n ..\n} // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\niter.find(|x| x == 0).is_some()\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y;\nlet x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```ignore\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X {\n ..\n }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```ignore\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g., `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => (),\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let else` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "Using `match`:\n\n```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(other_ref),\n}\n```\n\nUsing `if let` with `else`:\n\n```rust\nif let Some(ref foo) = x {\n bar(foo);\n} else {\n bar(other_ref);\n}\n```" + } + }, + { + "id": "slow_vector_initialization", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks slow zero-filled vector initialization", + "Why is this bad": "These structures are non-idiomatic and less efficient than simply using\n`vec![0; len]`.", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nvec1.resize(len, 0);\n\nlet mut vec2 = Vec::with_capacity(len);\nvec2.extend(repeat(0).take(len))\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore, some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\"\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def);\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g., `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else`. It lints if the `else`\nis followed immediately by a newline or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} { // looks like an `else` is missing here\n}\n\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\n{ // this is the `else` block of the previous `if`, but should it be?\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n ..\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "too_many_lines", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions with a large amount of lines.", + "Why is this bad": "Functions with a lot of lines are harder to understand\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.", + "Known problems": "None.", + "Example": "``` rust\nfn im_too_long() {\nprintln!(\"\");\n// ... 100 more LoC\nprintln!(\"\");\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-lines-threshold: u64`: The maximum number of lines a function or method can have (defaults to `100 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g., changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool {\n true\n}\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet _: &str = std::mem::transmute(b); // where b: &[u8]\n\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet _: bool = std::mem::transmute(x); // where x: u8\n\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet _: char = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "Transmutes are dangerous and error-prone, whereas `from_bits` is intuitive\nand safe.", + "Known problems": "None.", + "Example": "```rust\nlet _: f32 = std::mem::transmute(x); // where x: u32\n\n// should be:\nlet _: f32 = f32::from_bits(x);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust\nlet _: &T = std::mem::transmute(p); // where p: *const T\n\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "transmuting_null", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmute calls which would receive a null pointer.", + "Why is this bad": "Transmuting a null pointer is undefined behavior.", + "Known problems": "Not all cases can be detected at the moment of this writing.\nFor example, variables which hold a null pointer and are then fed to a `transmute`\ncall, aren't detectable yet.", + "Example": "```rust\nlet null_ref: &u64 = unsafe { std::mem::transmute(0 as *const u64) };\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\nfn foo(v: &u32) {\n assert_eq!(v, 42);\n}\n// should be\nfn foo(v: u32) {\n assert_eq!(v, 42);\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \u201ca\u0300\u201d and \u201c\u00e0\u201d aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```no_run\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a\nunit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif {\n foo();\n} == {\n bar();\n} {\n baz();\n}\n```\nis equal to\n```rust\n{\n foo();\n bar();\n baz();\n}\n```" + } + }, + { + "id": "unknown_clippy_lints", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `allow`/`warn`/`deny`/`forbid` attributes with scoped clippy\nlints and if those lints exist in clippy. If there is an uppercase letter in the lint name\n(not the tool name) and a lowercase version of this lint exists, it will suggest to lowercase\nthe lint name.", + "Why is this bad": "A lint attribute with a mistyped lint name won't have an effect.", + "Known problems": "None.", + "Example": "Bad:\n```rust\n#![warn(if_not_els)]\n#![deny(clippy::All)]\n```\n\nGood:\n```rust\n#![warn(if_not_else)]\n#![deny(clippy::all)]\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```ignore\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "Limitations of the borrow checker might make unwrap() necessary sometimes?", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```ignore\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 61864918973511;\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unsafe_vector_initialization", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```ignore\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g., the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () {\n ()\n}\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "- False positive when using associated types (#2843)\n- False positives in some situations when using generics (#3410)", + "Example": "```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```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]`, `#[allow(deprecated)]` and\n`#[allow(unreachable_pub)]` on `use` items and `#[allow(unused_imports)]` on\n`extern crate` items with a `#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```ignore\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"foo\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\")\nformat!(\"{}\", foo)\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust\ncore::intrinsics::transmute(t) // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "vec_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Vec>` where T: Sized anywhere in the code.", + "Why is this bad": "`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.", + "Known problems": "Vec> makes sense if T is a large type (see #3530,\n1st comment).", + "Example": "```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nif x & 0x1111 == 0 { }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n }\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n}\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```ignore\nwhile let Some(val) = iter() {\n ..\n}\n```" + } + }, + { + "id": "wildcard_dependencies", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard dependencies in the `Cargo.toml`.", + "Why is this bad": "[As the edition guide says](https://rust-lang-nursery.github.io/edition-guide/rust-2018/cargo-and-crates-io/crates-io-disallows-wildcard-dependencies.html),\nit is highly unlikely that you work with any possible version of your dependency,\nand wildcard dependencies would cause unnecessary breakage in the ecosystem.", + "Known problems": "None.", + "Example": "```toml\n[dependencies]\nregex = \"*\"\n```" + } + }, + { + "id": "wildcard_enum_match_arm", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard enum matches using `_`.", + "Why is this bad": "New enum variants added by library updates can be missed.", + "Known problems": "Suggested replacements may be incorrect if guards exhaustively cover some\nvariants, and also may not use correct path to enum if it's not present in the current scope.", + "Example": "```rust\nmatch x {\n A => {},\n _ => {},\n}\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(buf, \"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl X {\n pub fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```ignore\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\nlet a = 0 as *const u32;\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.38.0/index.html b/rust-1.38.0/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.38.0/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.38.0/lints.json b/rust-1.38.0/lints.json new file mode 100644 index 000000000000..6e31109d73c0 --- /dev/null +++ b/rust-1.38.0/lints.json @@ -0,0 +1,3473 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat it is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g., 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nlet vec: Vec = vec![];\nif vec.len() <= 0 {}\nif 100 > std::i32::MAX {}\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust\na = b;\nb = a;\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "None.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assertions_on_constants", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `assert!(true)` and `assert!(false)` calls.", + "Why is this bad": "Will be optimized out by the compiler or should probably be replaced by a\npanic!() or unreachable!()", + "Known problems": "None", + "Example": "```rust,ignore\nassert!(false)\n// or\nassert!(true)\n// or\nconst B: bool = false;\nassert!(B)\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\nlet b = 0;\n// ...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } { /* ... */ }\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```ignore\nif { let x = somefunc(); x } {}\n// or\nif somefunc(|x| { x == 47 }) {}\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true`,\n`x != true` and order comparisons such as `x < true` (or vice versa) and\nsuggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x == true {} // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.,\ncontains a `Cell`, `Mutex`, `AtomicXxxx`, etc.) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust,ignore\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust,ignore\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust,ignore\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nfoo(*x);\nprintln!(\"{}\", *x);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cargo_common_metadata", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks 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", + "Why is this bad": "It will be more difficult for users to discover the\npurpose of the crate, and key information related to it.", + "Known problems": "None.", + "Example": "```toml\n# This `Cargo.toml` is missing an authors field:\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/Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```" + } + }, + { + "id": "cast_lossless", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 {\n x as u64\n}\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 {\n u64::from(x)\n}\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 {\n x as u8\n}\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e., nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nstd::u32::MAX as i32; // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = std::u64::MAX;\nx as f64;\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "Using `std::ptr::read_unaligned` and `std::ptr::write_unaligned` or similar\non the resulting pointer is fine.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_ref_to_mut", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of `&T` to `&mut T` anywhere in the code.", + "Why is this bad": "It\u2019s basically guaranteed to be undefined behaviour.\n`UnsafeCell` is the only way to obtain aliasable data that is considered\nmutable.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn x(r: &i32) {\n unsafe {\n *(r as *const _ as *mut _) += 1;\n }\n}\n```\n\nInstead consider using interior mutability types.\n\n```rust\nuse std::cell::UnsafeCell;\n\nfn x(r: &UnsafeCell) {\n unsafe {\n *r.get() += 1;\n }\n}\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128; // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust,ignore\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust,ignore\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```ignore\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nlet name = \"foo\";\nname.chars().next() == Some('_');\n```" + } + }, + { + "id": "checked_conversions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit bounds checking when casting.", + "Why is this bad": "Reduces the readability of statements & is error prone.", + "Known problems": "None.", + "Example": "```rust\nfoo <= i32::max_value() as u32\n```\n\nCould be written:\n\n```rust\ni32::try_from(foo).is_ok()\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\", *y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone();\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g., `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nlet x = Rc::new(1);\nx.clone();\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\n\nif x == NAN { }\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```ignore\nif x == ptr::null {\n ..\n}\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nif x.to_owned() == y {}\n```" + } + }, + { + "id": "cognitive_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cognitive complexity.", + "Why is this bad": "Methods of high cognitive complexity tend to be hard to\nboth read and maintain. Also LLVM will tend to optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cognitive-complexity-threshold: u64`: The maximum cognitive complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust,ignore\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust,ignore\ncore::intrinsics::transmute(t) // where the result type is the same as\n // `*t` or `&t`'s\n```" + } + }, + { + "id": "dbg_macro", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of dbg!() macro.", + "Why is this bad": "`dbg!` macro is intended as a debugging tool. It\nshould not be in version control.", + "Known problems": "None.", + "Example": "```rust,ignore\n// Bad\ndbg!(true)\n\n// Good\ntrue\n```" + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g., contains a `Cell`, `Mutex`, `AtomicXxxx`, etc.).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g., the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_cfg_attr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.", + "Why is this bad": "Since 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.", + "Known problems": "This 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)", + "Example": "Bad:\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nGood:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else() { /* ... */ }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust,ignore\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```text\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```ignore\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust,no_run\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n \"CamelCase\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparisons that could be simplified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nif x == y || x < y {}\n```\n\nCould be written as:\n\n```rust\nif x <= y {}\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = 3;\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0));\nfoo((0));\n((1, 2));\n```" + } + }, + { + "id": "drop_bounds", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for generics with `std::ops::Drop` as bounds.", + "Why is this bad": "`Drop` bounds do not really accomplish anything.\nA type may have compiler-generated drop glue without implementing the\n`Drop` trait itself. The `Drop` trait also only has one method,\n`Drop::drop`, and that function is by fiat not callable in user code.\nSo there is really no use case for using `Drop` in trait bounds.\n\nThe most likely use case of a drop bound is to distinguish between types\nthat have destructors and types that don't. Combined with specialization,\na naive coder would write an implementation that assumed a type could be\ntrivially dropped, then write a specialization for `T: Drop` that actually\ncalls the destructor. Except that doing so is not correct; String, for\nexample, doesn't actually implement Drop, but because String contains a\nVec, assuming it can be trivially dropped will leak memory.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {}\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```ignore\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g., MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // We don't care about zero.\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine() { }\n\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code() { }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too() { }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```no_run\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0,\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nif x + 1 == x + 1 {}\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g., `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\nlet x = 1;\n0 / x;\n0 * x;\nx & 0;\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {\n x = 1;\n 1\n} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet v: f32 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789\n\n// Good\nlet v: f64 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantics of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg));\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str());\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|| panic!(\"Err {}: {}\", err_code, err_msg));\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust,ignore\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n // ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Not only is the version using `.enumerate()` more\nreadable, the compiler is able to remove bounds checks which can lead to\nfaster code in some instances.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..v.len() { foo(v[i]); }\nfor i in 0..v.len() { bar(i, v[i]); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() {\n // ..\n}\n```\ncan be rewritten to\n```rust\nfor x in y {\n // ..\n}\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() {\n // ..\n}\n```\ncan be rewritten to\n```rust\nfor x in &y {\n // ..\n}\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut std::io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) {\n // ..\n}\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\nlet vec = vec![1];\nvec.iter().filter(|x| **x == 0).map(|x| *x * 2);\n```" + } + }, + { + "id": "filter_map_next", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter_map(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().filter(|x| **x == 0).next();\n```" + } + }, + { + "id": "find_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.find(_).map(_)`.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\n (0..3).find(|x| *x == 2).map(|x| x * 2);\n```\nCan be written as\n```rust\n (0..3).find_map(|x| if x == 2 { Some(x * 2) } else { None });\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0;\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nlet x = 1.2331f64;\nlet y = 1.2332f64;\nif y == 1.23f64 { }\nif y != x {} // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nlet x: f64 = 1.0;\nconst ONE: f64 = 1.00;\nx == ONE; // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 { 1 }\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 { 1 }\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 {\n 1\n};\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 {\n 1\n};\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```ignore\nfor (k, _) in &map {\n ..\n}\n```\n\ncould be replaced by\n\n```ignore\nfor k in map.keys() {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in option {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Some(x) = option {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in result {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Ok(x) = result {\n ..\n}\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_last_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for using `x.get(x.len() - 1)` instead of\n`x.last()`.", + "Why is this bad": "Using `x.last()` is easier to read and has the same\nresult.\n\nNote that using `x[x.len() - 1]` is semantically different from\n`x.last()`. Indexing into the array will panic on out-of-bounds\naccesses, while `x.get()` and `x.last()` will return `None`.\n\nThere is another lint (get_unwrap) that covers the case of using\n`x.get(index).unwrap()` instead of `x[index]`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet x = vec![2, 3, 5];\nlet last_element = x.get(x.len() - 1);\n\n// Good\nlet x = vec![2, 3, 5];\nlet last_element = x.last();\n```" + } + }, + { + "id": "get_unwrap", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "Not a replacement for error handling: Using either\n`.unwrap()` or the Index trait (`[]`) carries the risk of causing a `panic`\nif the value being accessed is `None`. If the use of `.get().unwrap()` is a\ntemporary placeholder for dealing with the `Option` type, then this does\nnot mitigate the need for error handling. If there is a chance that `.get()`\nwill be `None` in your program, then it is advisable that the `None` case\nis handled in a future refactor instead of using `.unwrap()` or the Index\ntrait.", + "Example": "```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g., `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0;\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```ignore\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```ignore\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nif a == b {\n \u2026\n} else if a == b {\n \u2026\n}\n```\n\nNote that this lint ignores all conditions with a function call as it could\nhave side effects:\n\n```ignore\nif foo() {\n \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { }\n\npub fn foo(map: &mut HashMap) { }\n```\ncould be rewritten as\n```rust\nimpl Serialize for HashMap { }\n\npub fn foo(map: &mut HashMap) { }\n```" + } + }, + { + "id": "implicit_return", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for missing return statements at the end of a block.", + "Why is this bad": "Actually omitting the return keyword is idiomatic Rust code. Programmers\ncoming from other languages might prefer the expressiveness of `return`. It's possible to miss\nthe last returning statement because the only difference is a missing `;`. Especially in bigger\ncode with multiple return paths having a `return` keyword makes it easier to find the\ncorresponding statements.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: usize) -> usize {\n x\n}\n```\nadd return\n```rust\nfn foo(x: usize) -> usize {\n return x;\n}\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 618_64_9189_73_511;\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust,no_run\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```no_run\nuse std::iter;\n\niter::repeat(1_u8).collect::>();\n```" + } + }, + { + "id": "inherent_to_string", + "group": "style", + "level": "Warn", + "docs": { + "What id does": "Checks for the definition of inherent methods with a signature of `to_string(&self) -> String`.", + "Why is this bad": "This method is also implicitly defined if a type implements the `Display` trait. As the functionality of `Display` is much more versatile, it should be preferred.", + "Known problems": "None", + " Example": "```rust\n// Bad\npub struct A;\n\nimpl A {\n pub fn to_string(&self) -> String {\n \"I am A\".to_string()\n }\n}\n```\n\n```rust\n// Good\nuse std::fmt;\n\npub struct A;\n\nimpl fmt::Display for A {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n write!(f, \"I am A\")\n }\n}\n```" + } + }, + { + "id": "inherent_to_string_shadow_display", + "group": "correctness", + "level": "Deny", + "docs": { + "What id does": "Checks for the definition of inherent methods with a signature of `to_string(&self) -> String` and if the type implementing this method also implements the `Display` trait.", + "Why is this bad": "This method is also implicitly defined if a type implements the `Display` trait. The less versatile inherent method will then shadow the implementation introduced by `Display`.", + "Known problems": "None", + " Example": "```rust\n// Bad\nuse std::fmt;\n\npub struct A;\n\nimpl A {\n pub fn to_string(&self) -> String {\n \"I am A\".to_string()\n }\n}\n\nimpl fmt::Display for A {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n write!(f, \"I am A, too\")\n }\n}\n```\n\n```rust\n// Good\nuse std::fmt;\n\npub struct A;\n\nimpl fmt::Display for A {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n write!(f, \"I am A\")\n }\n}\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```ignore\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nif x >= y + 1 {}\n```\n\nCould be written as:\n\n```rust\nif x > y {}\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1;\n```" + } + }, + { + "id": "integer_division", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for division of integers", + "Why is this bad": "When outside of some very specific algorithms,\ninteger division is very often a mistake because it discards the\nremainder.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = 3 / 2;\n println!(\"{}\", x);\n}\n```" + } + }, + { + "id": "into_iter_on_array", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `into_iter` calls on types which should be replaced by `iter` or\n`iter_mut`.", + "Why is this bad": "Arrays and `PathBuf` do not yet have an `into_iter` method which move out\ntheir content into an iterator. Auto-referencing resolves the `into_iter` call to its reference\ninstead, like `<&[T; N] as IntoIterator>::into_iter`, which just iterates over item references\nlike calling `iter` would. Furthermore, when the standard library actually\n[implements the `into_iter` method](https://github.com/rust-lang/rust/issues/25725) which moves\nthe content out of the array, the original use of `into_iter` got inferred with the wrong type\nand the code will be broken.", + "Known problems": "None", + "Example": "```rust\nlet _ = [1, 2, 3].into_iter().map(|x| *x).collect::>();\n```" + } + }, + { + "id": "into_iter_on_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `into_iter` calls on references which should be replaced by `iter`\nor `iter_mut`.", + "Why is this bad": "Readability. Calling `into_iter` on a reference will not move out its\ncontent into the resulting iterator, which is confusing. It is better just call `iter` or\n`iter_mut` directly.", + "Known problems": "None", + "Example": "```rust\nlet _ = (&vec![3, 4, 5]).into_iter();\n```" + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang/rust-clippy/issues/886", + "Example": "```rust\nlet x: u8 = 1;\n(x as u32) > 300;\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```ignore\nfor x in y.next() {\n ..\n}\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```ignore\nfor x in (5..5).step_by(0) {\n ..\n}\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 6186491_8973511;\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a enum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n pub fn len(&self) -> usize {\n ..\n }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```ignore\nif x.len() == 0 {\n ..\n}\nif y.len() != 0 {\n ..\n}\n```\ninstead use\n```ignore\nif x.is_empty() {\n ..\n}\nif !y.is_empty() {\n ..\n}\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = {\n 1;\n};\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x: LinkedList = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```ignore\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "main_recursion", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for recursion using the entrypoint.", + "Why is this bad": "Apart from special setups (which we could detect following attributes like #![no_std]),\nrecursing into main() seems like an unintuitive antipattern we should be able to detect.", + "Known problems": "None.", + "Example": "```no_run\nfn main() {\n main();\n}\n```" + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust\nlet mut a = 42;\nlet mut b = 1337;\n\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nlet mut a = 1;\nlet mut b = 2;\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```ignore\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nif !map.contains_key(&k) {\n map.insert(k.clone(), v);\n}\n```", + "Example": "```rust\nif !map.contains_key(&k) {\n map.insert(k, v);\n}\n```\ncan both be rewritten as:\n```rust\nmap.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\nlet vec = vec![vec![1]];\nvec.iter().map(|x| x.iter()).flatten();\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1...10 => println!(\"1 ... 10\"),\n 5...15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust,ignore\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x: Result = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\nlet infinite_iter = 0..;\n[0..].iter().zip(infinite_iter.take_while(|x| *x > 5));\n```" + } + }, + { + "id": "mem_discriminant_non_enum", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `mem::discriminant()` on a non-enum type.", + "Why is this bad": "The value of `mem::discriminant()` on non-enum types\nis unspecified.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nmem::discriminant(&\"hello\");\nmem::discriminant(&&Some(2));\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```ignore\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore, it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\nlet b = 2;\n// ...\na += a + b;\n```" + } + }, + { + "id": "missing_const_for_fn", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Suggests the use of `const` in functions and methods where possible.", + "Why is this bad": "Not having the function const prevents callers of the function from being const as well.", + "Known problems": "Const 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.", + "Example": "```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```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make\nsense. It allows the crate to require all exported methods to be `#[inline]` by default, and\nthen opt out for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn private() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn private() {} // ok\n pub fn not_ptrivate() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32;\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```ignore\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "module_name_repetitions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nlet a = x % 1;\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```ignore\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::sync::atomic::AtomicBool` and `std::sync::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::sync::atomic::AtomicUsize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&vec.iter().filter(|x| **x == 0u8).count(); // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we, of course, do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust,ignore\nif x {\n false\n} else {\n true\n}\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "None." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust,ignore\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n (&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime mismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\nlet mut v = Vec::::new();\nlet _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.clone().collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n # break;\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n # break;\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 {\n x\n}\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n```\n\n```rust\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nlet vec = vec!['a', 'b', 'c'];\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```\nCould be written as:\n```rust\nlet vec = vec!['a', 'b', 'c'];\nfor i in vec {\n println!(\"{}\", i);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) -> usize {\n return x;\n}\n```\nsimplify to\n```rust\nfn foo(x: usize) -> usize {\n x\n}\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint {\n x: 1,\n y: 1,\n ..zero_point\n};\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g., `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```ignore\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop {\n ..;\n break;\n}\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).\n\nIt detects both the case when a manual\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\nimplementation is required and also when it can be created with\n`#[derive(Default)]`", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```ignore\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nOr, if\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\ncan be derived by `#[derive(Default)]`:\n\n```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nInstead, use:\n\n```rust\n#[derive(Default)]\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = String::from(\"\u20ac\");\n```\nCould be written as:\n```rust\nlet x = String::from(\"\\u{20ac}\");\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```ignore\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nuse std::fs::OpenOptions;\n\nOpenOptions::new().read(true).truncate(true);\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereference raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) {\n println!(\"{}\", unsafe { *x });\n}\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```ignore\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```ignore\n&x == y\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```ignore\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)));\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg);\n}\n\nif let Some(msg) = x {\n log_err_msg(format_msg(msg));\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0);\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function);\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}\n```" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "Using unwrap on an `Option`:\n\n```rust\nlet opt = Some(1);\nopt.unwrap();\n```\n\nBetter:\n\n```rust\nlet opt = Some(1);\nopt.expect(\"more helpful message\");\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new());\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new);\n```\nor\n```rust\nfoo.unwrap_or_default();\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```no_run\n# #![allow(const_err)]\nlet x = [1, 2, 3, 4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a;\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```no_run\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { true }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "path_buf_push_overwrite", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "* Checks for [push](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.push)\ncalls on `PathBuf` that can cause overwrites.", + "Why is this bad": "Calling `push` with a root path at the start can overwrite the\nprevious defined path.", + "Known problems": "None.", + "Example": "```rust\nuse std::path::PathBuf;\n\nlet mut x = PathBuf::from(\"/foo\");\nx.push(\"/bar\");\nassert_eq!(x, PathBuf::from(\"/bar\"));\n```\nCould be written:\n\n```rust\nuse std::path::PathBuf;\n\nlet mut x = PathBuf::from(\"/foo\");\nx.push(\"bar\");\nassert_eq!(x, PathBuf::from(\"/foo/bar\"));\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```ignore\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.offset(offset as isize);\n}\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.add(offset);\n}\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator.", + "Why is this bad": "Question mark usage is more idiomatic.", + "Known problems": "None", + "Example": "```ignore\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```ignore\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g., `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust,ignore\nfor x..=(y-1) { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g., `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e., `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust,ignore\nfor x..(y+1) { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len());\n```" + } + }, + { + "id": "redundant_clone", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for a redudant `clone()` (and its relatives) which clones an owned\nvalue that is going to be dropped without further use.", + "Why is this bad": "It is not always possible for the compiler to eliminate useless\nallocations and deallocations generated by redundant `clone()`s.", + "Known problems": "* Suggestions made by this lint could require NLL to be enabled.\n* False-positive if there is a borrow preventing the value from moving out.\n\n```rust\nlet x = String::new();\n\nlet y = &x;\n\nfoo(x.clone()); // This lint suggests to remove this `clone()`\n```", + "Example": "```rust\n{\n let x = Foo::new();\n call(x.clone());\n call(x.clone()); // this can just pass `x`\n}\n\n[\"lorem\", \"ipsum\"].join(\" \").to_string();\n\nPath::new(\"/a/b\").join(\"c\").to_path_buf();\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee rust-lang/rust-clippy#1439 for more details.", + "Example": "```rust,ignore\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust,ignore\n(|| 42)()\n```" + } + }, + { + "id": "redundant_closure_for_method_calls", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for closures which only invoke a method on the closure\nargument and can be replaced by referencing the method directly.", + "Why is this bad": "It's unnecessary to create the closure.", + "Known problems": "rust-lang/rust-clippy#3071, rust-lang/rust-clippy#4002,\nrust-lang/rust-clippy#3942", + "Example": "```rust,ignore\nSome('a').map(|s| s.to_uppercase());\n```\nmay be rewritten as\n```rust,ignore\nSome('a').map(char::to_uppercase);\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```ignore\nlet foo = Foo { bar };\n```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\n\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "redundant_static_lifetimes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants and statics with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```ignore\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```ignore\n const FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n static FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Point(30, 20);\nlet x = (&point).0;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```ignore\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)));\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg);\n};\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg));\n};\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function);\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "Using unwrap on an `Option`:\n\n```rust\nlet res: Result = Ok(1);\nres.unwrap();\n```\n\nBetter:\n\n```rust\nlet res: Result = Ok(1);\nres.expect(\"more helpful message\");\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```ignore\nfor x in 5..10 - 5 {\n ..\n} // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().find(|x| **x == 0).is_some();\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = 2;\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet x = 2;\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y;\nlet x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust,ignore\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```ignore\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X {\n ..\n }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```ignore\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g., `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => (),\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with a two arms where an `if let else` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "Using `match`:\n\n```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(&other_ref),\n}\n```\n\nUsing `if let` with `else`:\n\n```rust\nif let Some(ref foo) = x {\n bar(foo);\n} else {\n bar(&other_ref);\n}\n```" + } + }, + { + "id": "slow_vector_initialization", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks slow zero-filled vector initialization", + "Why is this bad": "These structures are non-idiomatic and less efficient than simply using\n`vec![0; len]`.", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nvec1.resize(len, 0);\n\nlet mut vec2 = Vec::with_capacity(len);\nvec2.extend(repeat(0).take(len))\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore, some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\";\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def);\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g., `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else`. It lints if the `else`\nis followed immediately by a newline or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} { // looks like an `else` is missing here\n}\n\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\n{ // this is the `else` block of the previous `if`, but should it be?\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n // ..\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "too_many_lines", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions with a large amount of lines.", + "Why is this bad": "Functions with a lot of lines are harder to understand\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.", + "Known problems": "None.", + "Example": "``` rust\nfn im_too_long() {\nprintln!(\"\");\n// ... 100 more LoC\nprintln!(\"\");\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-lines-threshold: u64`: The maximum number of lines a function or method can have (defaults to `100 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g., changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool {\n true\n}\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet b: &[u8] = &[1_u8, 2_u8];\nunsafe {\n let _: &str = std::mem::transmute(b); // where b: &[u8]\n}\n\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet x = 1_u8;\nunsafe {\n let _: bool = std::mem::transmute(x); // where x: u8\n}\n\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet x = 1_u32;\nunsafe {\n let _: char = std::mem::transmute(x); // where x: u32\n}\n\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "Transmutes are dangerous and error-prone, whereas `from_bits` is intuitive\nand safe.", + "Known problems": "None.", + "Example": "```rust\nunsafe {\n let _: f32 = std::mem::transmute(1_u32); // where x: u32\n}\n\n// should be:\nlet _: f32 = f32::from_bits(1_u32);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32;\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust,ignore\nunsafe {\n let _: &T = std::mem::transmute(p); // where p: *const T\n}\n\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "transmuting_null", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmute calls which would receive a null pointer.", + "Why is this bad": "Transmuting a null pointer is undefined behavior.", + "Known problems": "Not all cases can be detected at the moment of this writing.\nFor example, variables which hold a null pointer and are then fed to a `transmute`\ncall, aren't detectable yet.", + "Example": "```rust\nlet null_ref: &u64 = unsafe { std::mem::transmute(0 as *const u64) };\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\n// Bad\nfn foo(v: &u32) {}\n```\n\n```rust\n// Better\nfn foo(v: u32) {}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "try_err", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Err(x)?`.", + "Why is this bad": "The `?` operator is designed to allow calls that\ncan fail to be easily chained. For example, `foo()?.bar()` or\n`foo(bar()?)`. Because `Err(x)?` can't be used that way (it will\nalways return), it is more clear to write `return Err(x)`.", + "Known problems": "None.", + "Example": "```rust\nfn foo(fail: bool) -> Result {\n if fail {\n Err(\"failed\")?;\n }\n Ok(0)\n}\n```\nCould be written:\n\n```rust\nfn foo(fail: bool) -> Result {\n if fail {\n return Err(\"failed\".into());\n }\n Ok(0)\n}\n```" + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "type_repetition_in_bounds", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "This lint warns about unnecessary type repetitions in trait bounds", + "Why is this bad": "Repeating the type for every bound makes the code\nless readable than combining the bounds", + "Example": "```rust\npub fn foo(t: T) where T: Copy, T: Clone {}\n```\n\nCould be written as:\n\n```rust\npub fn foo(t: T) where T: Copy + Clone {}\n```" + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \"a\u0300\"\" and \"\u00e0\"\" aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```no_run\nunimplemented!();\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a\nunit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif {\n foo();\n} == {\n bar();\n} {\n baz();\n}\n```\nis equal to\n```rust\n{\n foo();\n bar();\n baz();\n}\n```" + } + }, + { + "id": "unknown_clippy_lints", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `allow`/`warn`/`deny`/`forbid` attributes with scoped clippy\nlints and if those lints exist in clippy. If there is an uppercase letter in the lint name\n(not the tool name) and a lowercase version of this lint exists, it will suggest to lowercase\nthe lint name.", + "Why is this bad": "A lint attribute with a mistyped lint name won't have an effect.", + "Known problems": "None.", + "Example": "Bad:\n```rust\n#![warn(if_not_els)]\n#![deny(clippy::All)]\n```\n\nGood:\n```rust\n#![warn(if_not_else)]\n#![deny(clippy::all)]\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32;\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```ignore\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust,ignore\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "None", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```ignore\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 61864918973511;\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unsafe_vector_initialization", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unused_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for using `collect()` on an iterator without using\nthe result.", + "Why is this bad": "It is more idiomatic to use a `for` loop over the\niterator instead.", + "Known problems": "None.", + "Example": "```ignore\nvec.iter().map(|x| /* some operation returning () */).collect::>();\n```" + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g., the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () {\n ()\n}\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "- False positive when using associated types (#2843)\n- False positives in some situations when using generics (#3410)", + "Example": "```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```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]`, `#[allow(deprecated)]` and\n`#[allow(unreachable_pub)]` on `use` items and `#[allow(unused_imports)]` on\n`extern crate` items with a `#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```ignore\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"foo\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\");\nformat!(\"{}\", foo);\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust,ignore\ncore::intrinsics::transmute(t); // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "vec_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Vec>` where T: Sized anywhere in the code.", + "Why is this bad": "`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.", + "Known problems": "Vec> makes sense if T is a large type (see #3530,\n1st comment).", + "Example": "```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nif x & 0x1111 == 0 { }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust,no_run\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n };\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n};\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```ignore\nwhile let Some(val) = iter() {\n ..\n}\n```" + } + }, + { + "id": "wildcard_dependencies", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard dependencies in the `Cargo.toml`.", + "Why is this bad": "[As the edition guide says](https://rust-lang-nursery.github.io/edition-guide/rust-2018/cargo-and-crates-io/crates-io-disallows-wildcard-dependencies.html),\nit is highly unlikely that you work with any possible version of your dependency,\nand wildcard dependencies would cause unnecessary breakage in the ecosystem.", + "Known problems": "None.", + "Example": "```toml\n[dependencies]\nregex = \"*\"\n```" + } + }, + { + "id": "wildcard_enum_match_arm", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard enum matches using `_`.", + "Why is this bad": "New enum variants added by library updates can be missed.", + "Known problems": "Suggested replacements may be incorrect if guards exhaustively cover some\nvariants, and also may not use correct path to enum if it's not present in the current scope.", + "Example": "```rust\nmatch x {\n A => {},\n _ => {},\n}\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(buf, \"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl<'a> X {\n pub fn as_str(self) -> &'a str {\n \"foo\"\n }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```ignore\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0;\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\nlet a = 0 as *const u32;\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.39.0/index.html b/rust-1.39.0/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.39.0/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.39.0/lints.json b/rust-1.39.0/lints.json new file mode 100644 index 000000000000..056115e19bcb --- /dev/null +++ b/rust-1.39.0/lints.json @@ -0,0 +1,3550 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat it is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g., 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nlet vec: Vec = vec![];\nif vec.len() <= 0 {}\nif 100 > std::i32::MAX {}\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust\na = b;\nb = a;\n```\nCould be written as:\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "None.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assertions_on_constants", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `assert!(true)` and `assert!(false)` calls.", + "Why is this bad": "Will be optimized out by the compiler or should probably be replaced by a\npanic!() or unreachable!()", + "Known problems": "None", + "Example": "```rust,ignore\nassert!(false)\n// or\nassert!(true)\n// or\nconst B: bool = false;\nassert!(B)\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\nlet b = 0;\n// ...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } { /* ... */ }\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```ignore\nif { let x = somefunc(); x } {}\n// or\nif somefunc(|x| { x == 47 }) {}\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true`,\n`x != true` and order comparisons such as `x < true` (or vice versa) and\nsuggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x == true {} // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.,\ncontains a `Cell`, `Mutex`, `AtomicXxxx`, etc.) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust,ignore\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust,ignore\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust,ignore\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nfoo(*x);\nprintln!(\"{}\", *x);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cargo_common_metadata", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks 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", + "Why is this bad": "It will be more difficult for users to discover the\npurpose of the crate, and key information related to it.", + "Known problems": "None.", + "Example": "```toml\n# This `Cargo.toml` is missing an authors field:\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/Apache-2.0\"\nkeywords = [\"clippy\", \"lint\", \"plugin\"]\ncategories = [\"development-tools\", \"development-tools::cargo-plugins\"]\n```" + } + }, + { + "id": "cast_lossless", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 {\n x as u64\n}\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 {\n u64::from(x)\n}\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 {\n x as u8\n}\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e., nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nstd::u32::MAX as i32; // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = std::u64::MAX;\nx as f64;\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "Using `std::ptr::read_unaligned` and `std::ptr::write_unaligned` or similar\non the resulting pointer is fine.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_ref_to_mut", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of `&T` to `&mut T` anywhere in the code.", + "Why is this bad": "It\u2019s basically guaranteed to be undefined behaviour.\n`UnsafeCell` is the only way to obtain aliasable data that is considered\nmutable.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn x(r: &i32) {\n unsafe {\n *(r as *const _ as *mut _) += 1;\n }\n}\n```\n\nInstead consider using interior mutability types.\n\n```rust\nuse std::cell::UnsafeCell;\n\nfn x(r: &UnsafeCell) {\n unsafe {\n *r.get() += 1;\n }\n}\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128; // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust,ignore\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust,ignore\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```ignore\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nlet name = \"foo\";\nif name.chars().next() == Some('_') {};\n```\nCould be written as\n```rust\nlet name = \"foo\";\nif name.starts_with('_') {};\n```" + } + }, + { + "id": "checked_conversions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit bounds checking when casting.", + "Why is this bad": "Reduces the readability of statements & is error prone.", + "Known problems": "None.", + "Example": "```rust\nfoo <= i32::max_value() as u32\n```\n\nCould be written:\n\n```rust\ni32::try_from(foo).is_ok()\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\", *y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone();\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g., `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nlet x = Rc::new(1);\nx.clone();\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\n\nif x == NAN { }\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```ignore\nif x == ptr::null {\n ..\n}\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nif x.to_owned() == y {}\n```\nCould be written as\n```rust\nif x == y {}\n```" + } + }, + { + "id": "cognitive_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cognitive complexity.", + "Why is this bad": "Methods of high cognitive complexity tend to be hard to\nboth read and maintain. Also LLVM will tend to optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cognitive-complexity-threshold: u64`: The maximum cognitive complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust,ignore\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust,ignore\ncore::intrinsics::transmute(t) // where the result type is the same as\n // `*t` or `&t`'s\n```" + } + }, + { + "id": "dbg_macro", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of dbg!() macro.", + "Why is this bad": "`dbg!` macro is intended as a debugging tool. It\nshould not be in version control.", + "Known problems": "None.", + "Example": "```rust,ignore\n// Bad\ndbg!(true)\n\n// Good\ntrue\n```" + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g., contains a `Cell`, `Mutex`, `AtomicXxxx`, etc.).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g., the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_cfg_attr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.", + "Why is this bad": "Since 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.", + "Known problems": "This 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)", + "Example": "Bad:\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nGood:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else() { /* ... */ }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust,ignore\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```text\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```ignore\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust,no_run\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n \"CamelCase\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparisons that could be simplified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nif x == y || x < y {}\n```\n\nCould be written as:\n\n```rust\nif x <= y {}\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = 3;\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0));\nfoo((0));\n((1, 2));\n```" + } + }, + { + "id": "drop_bounds", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for generics with `std::ops::Drop` as bounds.", + "Why is this bad": "`Drop` bounds do not really accomplish anything.\nA type may have compiler-generated drop glue without implementing the\n`Drop` trait itself. The `Drop` trait also only has one method,\n`Drop::drop`, and that function is by fiat not callable in user code.\nSo there is really no use case for using `Drop` in trait bounds.\n\nThe most likely use case of a drop bound is to distinguish between types\nthat have destructors and types that don't. Combined with specialization,\na naive coder would write an implementation that assumed a type could be\ntrivially dropped, then write a specialization for `T: Drop` that actually\ncalls the destructor. Except that doing so is not correct; String, for\nexample, doesn't actually implement Drop, but because String contains a\nVec, assuming it can be trivially dropped will leak memory.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {}\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```ignore\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g., MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // We don't care about zero.\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine() { }\n\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code() { }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too() { }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```no_run\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0,\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nif x + 1 == x + 1 {}\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g., `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\nlet x = 1;\n0 / x;\n0 * x;\nx & 0;\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {\n x = 1;\n 1\n} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet v: f32 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789\n\n// Good\nlet v: f64 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantics of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg));\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str());\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|| panic!(\"Err {}: {}\", err_code, err_msg));\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust,ignore\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n // ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Using `.enumerate()` makes the intent more clear,\ndeclutters the code and may be faster in some instances.", + "Known problems": "None.", + "Example": "```rust\nlet mut i = 0;\nfor item in &v {\n bar(i, *item);\n i += 1;\n}\n```\nCould be written as\n```rust\nfor (i, item) in v.iter().enumerate() { bar(i, *item); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() {\n // ..\n}\n```\ncan be rewritten to\n```rust\nfor x in y {\n // ..\n}\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() {\n // ..\n}\n```\ncan be rewritten to\n```rust\nfor x in &y {\n // ..\n}\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut std::io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) {\n // ..\n}\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\nlet vec = vec![1];\nvec.iter().filter(|x| **x == 0).map(|x| *x * 2);\n```" + } + }, + { + "id": "filter_map_next", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter_map(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().filter(|x| **x == 0).next();\n```\nCould be written as\n```rust\nvec.iter().find(|x| **x == 0);\n```" + } + }, + { + "id": "find_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.find(_).map(_)`.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\n (0..3).find(|x| *x == 2).map(|x| x * 2);\n```\nCan be written as\n```rust\n (0..3).find_map(|x| if x == 2 { Some(x * 2) } else { None });\n```" + } + }, + { + "id": "flat_map_identity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `flat_map(|x| x)`.", + "Why is this bad": "Readability, this can be written more concisely by using `flatten`.", + "Known problems": "None", + "Example": "```rust\niter.flat_map(|x| x);\n```\nCan be written as\n```rust\niter.flatten();\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0;\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nlet x = 1.2331f64;\nlet y = 1.2332f64;\nif y == 1.23f64 { }\nif y != x {} // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nlet x: f64 = 1.0;\nconst ONE: f64 = 1.00;\nx == ONE; // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 { 1 }\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 { 1 }\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 {\n 1\n};\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 {\n 1\n};\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```ignore\nfor (k, _) in &map {\n ..\n}\n```\n\ncould be replaced by\n\n```ignore\nfor k in map.keys() {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in option {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Some(x) = option {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in result {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Ok(x) = result {\n ..\n}\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_last_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for using `x.get(x.len() - 1)` instead of\n`x.last()`.", + "Why is this bad": "Using `x.last()` is easier to read and has the same\nresult.\n\nNote that using `x[x.len() - 1]` is semantically different from\n`x.last()`. Indexing into the array will panic on out-of-bounds\naccesses, while `x.get()` and `x.last()` will return `None`.\n\nThere is another lint (get_unwrap) that covers the case of using\n`x.get(index).unwrap()` instead of `x[index]`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet x = vec![2, 3, 5];\nlet last_element = x.get(x.len() - 1);\n\n// Good\nlet x = vec![2, 3, 5];\nlet last_element = x.last();\n```" + } + }, + { + "id": "get_unwrap", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "Not a replacement for error handling: Using either\n`.unwrap()` or the Index trait (`[]`) carries the risk of causing a `panic`\nif the value being accessed is `None`. If the use of `.get().unwrap()` is a\ntemporary placeholder for dealing with the `Option` type, then this does\nnot mitigate the need for error handling. If there is a chance that `.get()`\nwill be `None` in your program, then it is advisable that the `None` case\nis handled in a future refactor instead of using `.unwrap()` or the Index\ntrait.", + "Example": "```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g., `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0;\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```ignore\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```ignore\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nif a == b {\n \u2026\n} else if a == b {\n \u2026\n}\n```\n\nNote that this lint ignores all conditions with a function call as it could\nhave side effects:\n\n```ignore\nif foo() {\n \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (SipHash).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { }\n\npub fn foo(map: &mut HashMap) { }\n```\ncould be rewritten as\n```rust\nimpl Serialize for HashMap { }\n\npub fn foo(map: &mut HashMap) { }\n```" + } + }, + { + "id": "implicit_return", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for missing return statements at the end of a block.", + "Why is this bad": "Actually omitting the return keyword is idiomatic Rust code. Programmers\ncoming from other languages might prefer the expressiveness of `return`. It's possible to miss\nthe last returning statement because the only difference is a missing `;`. Especially in bigger\ncode with multiple return paths having a `return` keyword makes it easier to find the\ncorresponding statements.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: usize) -> usize {\n x\n}\n```\nadd return\n```rust\nfn foo(x: usize) -> usize {\n return x;\n}\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 618_64_9189_73_511;\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust,no_run\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { }\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```no_run\nuse std::iter;\n\niter::repeat(1_u8).collect::>();\n```" + } + }, + { + "id": "inherent_to_string", + "group": "style", + "level": "Warn", + "docs": { + "What id does": "Checks for the definition of inherent methods with a signature of `to_string(&self) -> String`.", + "Why is this bad": "This method is also implicitly defined if a type implements the `Display` trait. As the functionality of `Display` is much more versatile, it should be preferred.", + "Known problems": "None", + " Example": "```rust\n// Bad\npub struct A;\n\nimpl A {\n pub fn to_string(&self) -> String {\n \"I am A\".to_string()\n }\n}\n```\n\n```rust\n// Good\nuse std::fmt;\n\npub struct A;\n\nimpl fmt::Display for A {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n write!(f, \"I am A\")\n }\n}\n```" + } + }, + { + "id": "inherent_to_string_shadow_display", + "group": "correctness", + "level": "Deny", + "docs": { + "What id does": "Checks for the definition of inherent methods with a signature of `to_string(&self) -> String` and if the type implementing this method also implements the `Display` trait.", + "Why is this bad": "This method is also implicitly defined if a type implements the `Display` trait. The less versatile inherent method will then shadow the implementation introduced by `Display`.", + "Known problems": "None", + " Example": "```rust\n// Bad\nuse std::fmt;\n\npub struct A;\n\nimpl A {\n pub fn to_string(&self) -> String {\n \"I am A\".to_string()\n }\n}\n\nimpl fmt::Display for A {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n write!(f, \"I am A, too\")\n }\n}\n```\n\n```rust\n// Good\nuse std::fmt;\n\npub struct A;\n\nimpl fmt::Display for A {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n write!(f, \"I am A\")\n }\n}\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```ignore\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nif x >= y + 1 {}\n```\n\nCould be written as:\n\n```rust\nif x > y {}\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1;\n```" + } + }, + { + "id": "integer_division", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for division of integers", + "Why is this bad": "When outside of some very specific algorithms,\ninteger division is very often a mistake because it discards the\nremainder.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = 3 / 2;\n println!(\"{}\", x);\n}\n```" + } + }, + { + "id": "into_iter_on_array", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `into_iter` calls on types which should be replaced by `iter` or\n`iter_mut`.", + "Why is this bad": "Arrays and `PathBuf` do not yet have an `into_iter` method which move out\ntheir content into an iterator. Auto-referencing resolves the `into_iter` call to its reference\ninstead, like `<&[T; N] as IntoIterator>::into_iter`, which just iterates over item references\nlike calling `iter` would. Furthermore, when the standard library actually\n[implements the `into_iter` method](https://github.com/rust-lang/rust/issues/25725) which moves\nthe content out of the array, the original use of `into_iter` got inferred with the wrong type\nand the code will be broken.", + "Known problems": "None", + "Example": "```rust\nlet _ = [1, 2, 3].into_iter().map(|x| *x).collect::>();\n```\nCould be written as:\n```rust\nlet _ = [1, 2, 3].iter().map(|x| *x).collect::>();\n```" + } + }, + { + "id": "into_iter_on_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `into_iter` calls on references which should be replaced by `iter`\nor `iter_mut`.", + "Why is this bad": "Readability. Calling `into_iter` on a reference will not move out its\ncontent into the resulting iterator, which is confusing. It is better just call `iter` or\n`iter_mut` directly.", + "Known problems": "None", + "Example": "```rust\nlet _ = (&vec![3, 4, 5]).into_iter();\n```" + } + }, + { + "id": "invalid_ref", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang/rust-clippy/issues/886", + "Example": "```rust\nlet x: u8 = 1;\n(x as u32) > 300;\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```ignore\nfor x in y.next() {\n ..\n}\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```ignore\nfor x in (5..5).step_by(0) {\n ..\n}\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 6186491_8973511;\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a enum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n pub fn len(&self) -> usize {\n ..\n }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```ignore\nif x.len() == 0 {\n ..\n}\nif y.len() != 0 {\n ..\n}\n```\ninstead use\n```ignore\nif x.is_empty() {\n ..\n}\nif !y.is_empty() {\n ..\n}\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = {\n 1;\n};\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x: LinkedList = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```ignore\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "main_recursion", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for recursion using the entrypoint.", + "Why is this bad": "Apart from special setups (which we could detect following attributes like #![no_std]),\nrecursing into main() seems like an unintuitive antipattern we should be able to detect.", + "Known problems": "None.", + "Example": "```no_run\nfn main() {\n main();\n}\n```" + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```\nCould be written as:\n```rust\ndst[64..(src.len() + 64)].clone_from_slice(&src[..]);\n```" + } + }, + { + "id": "manual_saturating_arithmetic", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `.checked_add/sub(x).unwrap_or(MAX/MIN)`.", + "Why is this bad": "These can be written simply with `saturating_add/sub` methods.", + "Example": "```rust\nlet add = x.checked_add(y).unwrap_or(u32::max_value());\nlet sub = x.checked_sub(y).unwrap_or(u32::min_value());\n```\n\ncan be written using dedicated methods for saturating addition/subtraction as:\n\n```rust\nlet add = x.saturating_add(y);\nlet sub = x.saturating_sub(y);\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust\nlet mut a = 42;\nlet mut b = 1337;\n\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nlet mut a = 1;\nlet mut b = 2;\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```ignore\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nif !map.contains_key(&k) {\n map.insert(k.clone(), v);\n}\n```", + "Example": "```rust\nif !map.contains_key(&k) {\n map.insert(k, v);\n}\n```\ncan both be rewritten as:\n```rust\nmap.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\nlet vec = vec![vec![1]];\nvec.iter().map(|x| x.iter()).flatten();\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1...10 => println!(\"1 ... 10\"),\n 5...15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust,ignore\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x: Result = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\nlet infinite_iter = 0..;\n[0..].iter().zip(infinite_iter.take_while(|x| *x > 5));\n```" + } + }, + { + "id": "mem_discriminant_non_enum", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `mem::discriminant()` on a non-enum type.", + "Why is this bad": "The value of `mem::discriminant()` on non-enum types\nis unspecified.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nmem::discriminant(&\"hello\");\nmem::discriminant(&&Some(2));\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "mem_replace_with_uninit", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `mem::replace(&mut _, mem::uninitialized())`\nand `mem::replace(&mut _, mem::zeroed())`.", + "Why is this bad": "This will lead to undefined behavior even if the\nvalue is overwritten later, because the uninitialized value may be\nobserved in the case of a panic.", + "Known problems": "None.", + "Example": "```\nuse std::mem;\n# fn may_panic(v: Vec) -> Vec { v }\n\n#[allow(deprecated, invalid_value)]\nfn myfunc (v: &mut Vec) {\n let taken_v = unsafe { mem::replace(v, mem::uninitialized()) };\n let new_v = may_panic(taken_v); // undefined behavior on panic\n mem::forget(mem::replace(v, new_v));\n}\n```\n\nThe [take_mut](https://docs.rs/take_mut) crate offers a sound solution,\nat the cost of either lazily creating a replacement value or aborting\non panic, to ensure that the uninitialized value cannot be observed." + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```ignore\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore, it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\nlet b = 2;\n// ...\na += a + b;\n```" + } + }, + { + "id": "missing_const_for_fn", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Suggests the use of `const` in functions and methods where possible.", + "Why is this bad": "Not having the function const prevents callers of the function from being const as well.", + "Known problems": "Const 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.", + "Example": "```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```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make\nsense. It allows the crate to require all exported methods to be `#[inline]` by default, and\nthen opt out for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn private() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn private() {} // ok\n pub fn not_ptrivate() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "missing_safety_doc", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the doc comments of publicly visible\nunsafe functions and warns if there is no `# Safety` section.", + "Why is this bad": "Unsafe functions should document their safety\npreconditions, so that users can be sure they are using them safely.", + "Known problems": "None.", + "Examples": ":\n```rust\n/// This function should really be documented\npub unsafe fn start_apocalypse(u: &mut Universe) {\n unimplemented!();\n}\n```\n\nAt least write a line about safety:\n\n```rust\n/// # Safety\n///\n/// This function should not be called before the horsemen are ready.\npub unsafe fn start_apocalypse(u: &mut Universe) {\n unimplemented!();\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n\t\tsuffix is required\n\t\t- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32;\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```ignore\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "module_name_repetitions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nlet a = x % 1;\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```ignore\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::sync::atomic::AtomicBool` and `std::sync::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::sync::atomic::AtomicUsize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&vec.iter().filter(|x| **x == 0u8).count(); // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we, of course, do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust,ignore\nif x {\n false\n} else {\n true\n}\n```\nCould be written as\n```rust,ignore\n!x\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "None." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust,ignore\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n (&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime mismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\nlet mut v = Vec::::new();\nlet _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.clone().collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n # break;\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n # break;\n}\n```" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 {\n x\n}\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n```\n\n```rust\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nlet vec = vec!['a', 'b', 'c'];\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```\nCould be written as:\n```rust\nlet vec = vec!['a', 'b', 'c'];\nfor i in vec {\n println!(\"{}\", i);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) -> usize {\n return x;\n}\n```\nsimplify to\n```rust\nfn foo(x: usize) -> usize {\n x\n}\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint {\n x: 1,\n y: 1,\n ..zero_point\n};\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g., `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```ignore\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop {\n ..;\n break;\n}\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).\n\nIt detects both the case when a manual\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\nimplementation is required and also when it can be created with\n`#[derive(Default)]`", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```ignore\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nOr, if\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\ncan be derived by `#[derive(Default)]`:\n\n```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nInstead, use:\n\n```rust\n#[derive(Default)]\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = String::from(\"\u20ac\");\n```\nCould be written as:\n```rust\nlet x = String::from(\"\\u{20ac}\");\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```ignore\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nuse std::fs::OpenOptions;\n\nOpenOptions::new().read(true).truncate(true);\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereference raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) {\n println!(\"{}\", unsafe { *x });\n}\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```ignore\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```ignore\n&x == y\n```" + } + }, + { + "id": "option_and_then_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.and_then(|x| Some(y))`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map(|x| y)`.", + "Known problems": "None", + "Example": "```rust\nlet x = Some(\"foo\");\nlet _ = x.and_then(|s| Some(s.len()));\n```\n\nThe correct use would be:\n\n```rust\nlet x = Some(\"foo\");\nlet _ = x.map(|s| s.len());\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```ignore\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)));\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg);\n}\n\nif let Some(msg) = x {\n log_err_msg(format_msg(msg));\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0);\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function);\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}\n```" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "Using unwrap on an `Option`:\n\n```rust\nlet opt = Some(1);\nopt.unwrap();\n```\n\nBetter:\n\n```rust\nlet opt = Some(1);\nopt.expect(\"more helpful message\");\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new());\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new);\n```\nor\n```rust\nfoo.unwrap_or_default();\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```no_run\n# #![allow(const_err)]\nlet x = [1, 2, 3, 4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a;\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```no_run\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { true }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "path_buf_push_overwrite", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "* Checks for [push](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.push)\ncalls on `PathBuf` that can cause overwrites.", + "Why is this bad": "Calling `push` with a root path at the start can overwrite the\nprevious defined path.", + "Known problems": "None.", + "Example": "```rust\nuse std::path::PathBuf;\n\nlet mut x = PathBuf::from(\"/foo\");\nx.push(\"/bar\");\nassert_eq!(x, PathBuf::from(\"/bar\"));\n```\nCould be written:\n\n```rust\nuse std::path::PathBuf;\n\nlet mut x = PathBuf::from(\"/foo\");\nx.push(\"bar\");\nassert_eq!(x, PathBuf::from(\"/foo/bar\"));\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```ignore\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.offset(offset as isize);\n}\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.add(offset);\n}\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator.", + "Why is this bad": "Question mark usage is more idiomatic.", + "Known problems": "None", + "Example": "```ignore\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```ignore\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g., `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust,ignore\nfor x..=(y-1) { .. }\n```\nCould be written as\n```rust,ignore\nfor x..y { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g., `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e., `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust,ignore\nfor x..(y+1) { .. }\n```\nCould be written as\n```rust,ignore\nfor x..=y { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len());\n```\nCould be written as\n```rust\nx.iter().enumerate();\n```" + } + }, + { + "id": "redundant_clone", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for a redudant `clone()` (and its relatives) which clones an owned\nvalue that is going to be dropped without further use.", + "Why is this bad": "It is not always possible for the compiler to eliminate useless\nallocations and deallocations generated by redundant `clone()`s.", + "Known problems": "* Suggestions made by this lint could require NLL to be enabled.\n* False-positive if there is a borrow preventing the value from moving out.\n\n```rust\nlet x = String::new();\n\nlet y = &x;\n\nfoo(x.clone()); // This lint suggests to remove this `clone()`\n```", + "Example": "```rust\n{\n let x = Foo::new();\n call(x.clone());\n call(x.clone()); // this can just pass `x`\n}\n\n[\"lorem\", \"ipsum\"].join(\" \").to_string();\n\nPath::new(\"/a/b\").join(\"c\").to_path_buf();\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee rust-lang/rust-clippy#1439 for more details.", + "Example": "```rust,ignore\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust,ignore\n(|| 42)()\n```" + } + }, + { + "id": "redundant_closure_for_method_calls", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for closures which only invoke a method on the closure\nargument and can be replaced by referencing the method directly.", + "Why is this bad": "It's unnecessary to create the closure.", + "Known problems": "rust-lang/rust-clippy#3071, rust-lang/rust-clippy#4002,\nrust-lang/rust-clippy#3942", + "Example": "```rust,ignore\nSome('a').map(|s| s.to_uppercase());\n```\nmay be rewritten as\n```rust,ignore\nSome('a').map(char::to_uppercase);\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```ignore\nlet foo = Foo { bar };\n```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\n\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "redundant_static_lifetimes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants and statics with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```ignore\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```ignore\n const FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n static FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Point(30, 20);\nlet x = (&point).0;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```ignore\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)));\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg);\n};\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg));\n};\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function);\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "Using unwrap on an `Option`:\n\n```rust\nlet res: Result = Ok(1);\nres.unwrap();\n```\n\nBetter:\n\n```rust\nlet res: Result = Ok(1);\nres.expect(\"more helpful message\");\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```ignore\nfor x in 5..10 - 5 {\n ..\n} // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().find(|x| **x == 0).is_some();\n```\nCould be written as\n```rust\nvec.iter().any(|x| *x == 0);\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = 2;\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet x = 2;\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y;\nlet x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust,ignore\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```ignore\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X {\n ..\n }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```ignore\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g., `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => (),\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with two arms where an `if let else` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "Using `match`:\n\n```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(&other_ref),\n}\n```\n\nUsing `if let` with `else`:\n\n```rust\nif let Some(ref foo) = x {\n bar(foo);\n} else {\n bar(&other_ref);\n}\n```" + } + }, + { + "id": "slow_vector_initialization", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks slow zero-filled vector initialization", + "Why is this bad": "These structures are non-idiomatic and less efficient than simply using\n`vec![0; len]`.", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nvec1.resize(len, 0);\n\nlet mut vec2 = Vec::with_capacity(len);\nvec2.extend(repeat(0).take(len))\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore, some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\";\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def);\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g., `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else`. It lints if the `else`\nis followed immediately by a newline or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} { // looks like an `else` is missing here\n}\n\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\n{ // this is the `else` block of the previous `if`, but should it be?\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `map` followed by a `count`.", + "Why is this bad": "It looks suspicious. Maybe `map` was confused with `filter`.\nIf the `map` call is intentional, this should be rewritten.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).map(|x| x + 2).count();\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n // ..\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "too_many_lines", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions with a large amount of lines.", + "Why is this bad": "Functions with a lot of lines are harder to understand\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.", + "Known problems": "None.", + "Example": "``` rust\nfn im_too_long() {\nprintln!(\"\");\n// ... 100 more LoC\nprintln!(\"\");\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-lines-threshold: u64`: The maximum number of lines a function or method can have (defaults to `100 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g., changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool {\n true\n}\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet b: &[u8] = &[1_u8, 2_u8];\nunsafe {\n let _: &str = std::mem::transmute(b); // where b: &[u8]\n}\n\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet x = 1_u8;\nunsafe {\n let _: bool = std::mem::transmute(x); // where x: u8\n}\n\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet x = 1_u32;\nunsafe {\n let _: char = std::mem::transmute(x); // where x: u32\n}\n\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "Transmutes are dangerous and error-prone, whereas `from_bits` is intuitive\nand safe.", + "Known problems": "None.", + "Example": "```rust\nunsafe {\n let _: f32 = std::mem::transmute(1_u32); // where x: u32\n}\n\n// should be:\nlet _: f32 = f32::from_bits(1_u32);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32;\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust,ignore\nunsafe {\n let _: &T = std::mem::transmute(p); // where p: *const T\n}\n\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "transmuting_null", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmute calls which would receive a null pointer.", + "Why is this bad": "Transmuting a null pointer is undefined behavior.", + "Known problems": "Not all cases can be detected at the moment of this writing.\nFor example, variables which hold a null pointer and are then fed to a `transmute`\ncall, aren't detectable yet.", + "Example": "```rust\nlet null_ref: &u64 = unsafe { std::mem::transmute(0 as *const u64) };\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\n// Bad\nfn foo(v: &u32) {}\n```\n\n```rust\n// Better\nfn foo(v: u32) {}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "try_err", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Err(x)?`.", + "Why is this bad": "The `?` operator is designed to allow calls that\ncan fail to be easily chained. For example, `foo()?.bar()` or\n`foo(bar()?)`. Because `Err(x)?` can't be used that way (it will\nalways return), it is more clear to write `return Err(x)`.", + "Known problems": "None.", + "Example": "```rust\nfn foo(fail: bool) -> Result {\n if fail {\n Err(\"failed\")?;\n }\n Ok(0)\n}\n```\nCould be written:\n\n```rust\nfn foo(fail: bool) -> Result {\n if fail {\n return Err(\"failed\".into());\n }\n Ok(0)\n}\n```" + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "type_repetition_in_bounds", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "This lint warns about unnecessary type repetitions in trait bounds", + "Why is this bad": "Repeating the type for every bound makes the code\nless readable than combining the bounds", + "Example": "```rust\npub fn foo(t: T) where T: Copy, T: Clone {}\n```\n\nCould be written as:\n\n```rust\npub fn foo(t: T) where T: Copy + Clone {}\n```" + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \"a\u0300\"\" and \"\u00e0\"\" aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```no_run\nunimplemented!();\n```" + } + }, + { + "id": "uninit_assumed_init", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `MaybeUninit::uninit().assume_init()`.", + "Why is this bad": "For most types, this is undefined behavior.", + "Known problems": "For now, we accept empty tuples and tuples / arrays\nof `MaybeUninit`. There may be other types that allow uninitialized\ndata, but those are not yet rigorously defined.", + "Example": "```rust\n// Beware the UB\nuse std::mem::MaybeUninit;\n\nlet _: usize = unsafe { MaybeUninit::uninit().assume_init() };\n```\n\nNote that the following is OK:\n\n```rust\nuse std::mem::MaybeUninit;\n\nlet _: [MaybeUninit; 5] = unsafe {\n MaybeUninit::uninit().assume_init()\n};\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a\nunit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif {\n foo();\n} == {\n bar();\n} {\n baz();\n}\n```\nis equal to\n```rust\n{\n foo();\n bar();\n baz();\n}\n```" + } + }, + { + "id": "unknown_clippy_lints", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `allow`/`warn`/`deny`/`forbid` attributes with scoped clippy\nlints and if those lints exist in clippy. If there is an uppercase letter in the lint name\n(not the tool name) and a lowercase version of this lint exists, it will suggest to lowercase\nthe lint name.", + "Why is this bad": "A lint attribute with a mistyped lint name won't have an effect.", + "Known problems": "None.", + "Example": "Bad:\n```rust\n#![warn(if_not_els)]\n#![deny(clippy::All)]\n```\n\nGood:\n```rust\n#![warn(if_not_else)]\n#![deny(clippy::all)]\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32;\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```ignore\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust,ignore\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "None", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```ignore\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 61864918973511;\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unsafe_vector_initialization", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unused_collect", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g., the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () {\n ()\n}\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "- False positive when using associated types (#2843)\n- False positives in some situations when using generics (#3410)", + "Example": "```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```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]`, `#[allow(deprecated)]` and\n`#[allow(unreachable_pub)]` on `use` items and `#[allow(unused_imports)]` on\n`extern crate` items with a `#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```ignore\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"foo\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\");\nformat!(\"{}\", foo);\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust,ignore\ncore::intrinsics::transmute(t); // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "vec_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Vec>` where T: Sized anywhere in the code.", + "Why is this bad": "`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.", + "Known problems": "Vec> makes sense if T is a large type (see #3530,\n1st comment).", + "Example": "```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nif x & 0x1111 == 0 { }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust,no_run\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n };\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n};\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```ignore\nwhile let Some(val) = iter() {\n ..\n}\n```" + } + }, + { + "id": "wildcard_dependencies", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard dependencies in the `Cargo.toml`.", + "Why is this bad": "[As the edition guide says](https://rust-lang-nursery.github.io/edition-guide/rust-2018/cargo-and-crates-io/crates-io-disallows-wildcard-dependencies.html),\nit is highly unlikely that you work with any possible version of your dependency,\nand wildcard dependencies would cause unnecessary breakage in the ecosystem.", + "Known problems": "None.", + "Example": "```toml\n[dependencies]\nregex = \"*\"\n```" + } + }, + { + "id": "wildcard_enum_match_arm", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard enum matches using `_`.", + "Why is this bad": "New enum variants added by library updates can be missed.", + "Known problems": "Suggested replacements may be incorrect if guards exhaustively cover some\nvariants, and also may not use correct path to enum if it's not present in the current scope.", + "Example": "```rust\nmatch x {\n A => {},\n _ => {},\n}\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(buf, \"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl<'a> X {\n pub fn as_str(self) -> &'a str {\n \"foo\"\n }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```ignore\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0;\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\nlet a = 0 as *const u32;\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.40.0/index.html b/rust-1.40.0/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.40.0/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.40.0/lints.json b/rust-1.40.0/lints.json new file mode 100644 index 000000000000..6f91188b9177 --- /dev/null +++ b/rust-1.40.0/lints.json @@ -0,0 +1,3737 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat it is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g., 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nlet vec: Vec = vec![];\nif vec.len() <= 0 {}\nif 100 > std::i32::MAX {}\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust\na = b;\nb = a;\n```\nCould be written as:\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "None.", + "Example": "```rust\nlet x = 3.14;\n```" + } + }, + { + "id": "assertions_on_constants", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `assert!(true)` and `assert!(false)` calls.", + "Why is this bad": "Will be optimized out by the compiler or should probably be replaced by a\npanic!() or unreachable!()", + "Known problems": "None", + "Example": "```rust,ignore\nassert!(false)\n// or\nassert!(true)\n// or\nconst B: bool = false;\nassert!(B)\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\nlet b = 0;\n// ...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } { /* ... */ }\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```ignore\nif { let x = somefunc(); x } {}\n// or\nif somefunc(|x| { x == 47 }) {}\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true`,\n`x != true` and order comparisons such as `x < true` (or vice versa) and\nsuggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x == true {} // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.,\ncontains a `Cell`, `Mutex`, `AtomicXxxx`, etc.) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust,ignore\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust,ignore\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust,ignore\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nfoo(*x);\nprintln!(\"{}\", *x);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cargo_common_metadata", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks 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", + "Why is this bad": "It will be more difficult for users to discover the\npurpose of the crate, and key information related to it.", + "Known problems": "None.", + "Example": "```toml\n# This `Cargo.toml` is missing an authors field:\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```" + } + }, + { + "id": "cast_lossless", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 {\n x as u64\n}\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 {\n u64::from(x)\n}\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 {\n x as u8\n}\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e., nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nstd::u32::MAX as i32; // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = std::u64::MAX;\nx as f64;\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "Using `std::ptr::read_unaligned` and `std::ptr::write_unaligned` or similar\non the resulting pointer is fine.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_ref_to_mut", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of `&T` to `&mut T` anywhere in the code.", + "Why is this bad": "It\u2019s basically guaranteed to be undefined behaviour.\n`UnsafeCell` is the only way to obtain aliasable data that is considered\nmutable.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn x(r: &i32) {\n unsafe {\n *(r as *const _ as *mut _) += 1;\n }\n}\n```\n\nInstead consider using interior mutability types.\n\n```rust\nuse std::cell::UnsafeCell;\n\nfn x(r: &UnsafeCell) {\n unsafe {\n *r.get() += 1;\n }\n}\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128; // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust,ignore\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust,ignore\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```ignore\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nlet name = \"foo\";\nif name.chars().next() == Some('_') {};\n```\nCould be written as\n```rust\nlet name = \"foo\";\nif name.starts_with('_') {};\n```" + } + }, + { + "id": "checked_conversions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit bounds checking when casting.", + "Why is this bad": "Reduces the readability of statements & is error prone.", + "Known problems": "None.", + "Example": "```rust\nfoo <= i32::max_value() as u32\n```\n\nCould be written:\n\n```rust\ni32::try_from(foo).is_ok()\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\", *y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone();\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g., `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nlet x = Rc::new(1);\nx.clone();\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\n\nif x == NAN { }\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```ignore\nif x == ptr::null {\n ..\n}\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nif x.to_owned() == y {}\n```\nCould be written as\n```rust\nif x == y {}\n```" + } + }, + { + "id": "cognitive_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cognitive complexity.", + "Why is this bad": "Methods of high cognitive complexity tend to be hard to\nboth read and maintain. Also LLVM will tend to optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cognitive-complexity-threshold: u64`: The maximum cognitive complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "comparison_chain", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks comparison chains written with `if` that can be\nrewritten with `match` and `cmp`.", + "Why is this bad": "`if` is not guaranteed to be exhaustive and conditionals can get\nrepetitive", + "Known problems": "None.", + "Example": "```rust,ignore\nfn f(x: u8, y: u8) {\n if x > y {\n a()\n } else if x < y {\n b()\n } else {\n c()\n }\n}\n```\n\nCould be written:\n\n```rust,ignore\nuse std::cmp::Ordering;\nfn f(x: u8, y: u8) {\n match x.cmp(&y) {\n Ordering::Greater => a(),\n Ordering::Less => b(),\n Ordering::Equal => c()\n }\n}\n```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust,ignore\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust,ignore\ncore::intrinsics::transmute(t) // where the result type is the same as\n // `*t` or `&t`'s\n```" + } + }, + { + "id": "dbg_macro", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of dbg!() macro.", + "Why is this bad": "`dbg!` macro is intended as a debugging tool. It\nshould not be in version control.", + "Known problems": "None.", + "Example": "```rust,ignore\n// Bad\ndbg!(true)\n\n// Good\ntrue\n```" + } + }, + { + "id": "debug_assert_with_mut_call", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for function/method calls with a mutable\nparameter in `debug_assert!`, `debug_assert_eq!` and `debug_assert_ne!` macros.", + "Why is this bad": "In release builds `debug_assert!` macros are optimized out by the\ncompiler.\nTherefore mutating something in a `debug_assert!` macro results in different behaviour\nbetween a release and debug build.", + "Known problems": "None", + "Example": "```rust,ignore\ndebug_assert_eq!(vec![3].pop(), Some(3));\n// or\nfn take_a_mut_parameter(_: &mut u32) -> bool { unimplemented!() }\ndebug_assert!(take_a_mut_parameter(&mut 5));\n```" + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g., contains a `Cell`, `Mutex`, `AtomicXxxx`, etc.).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g., the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_cfg_attr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.", + "Why is this bad": "Since 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.", + "Known problems": "This 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)", + "Example": "Bad:\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nGood:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else() { /* ... */ }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust,ignore\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```text\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```ignore\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust,no_run\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n \"CamelCase\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparisons that could be simplified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nif x == y || x < y {}\n```\n\nCould be written as:\n\n```rust\nif x <= y {}\n```" + } + }, + { + "id": "double_must_use", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for a [`#[must_use]`] attribute without\nfurther information on functions and methods that return a type already\nmarked as `#[must_use]`.\n\n[`#[must_use]`]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute", + "Why is this bad": "The attribute isn't needed. Not using the result\nwill already be reported. Alternatively, one can add some text to the\nattribute to improve the lint message.", + "Known problems": "None.", + "Examples": "```rust\n#[must_use]\nfn double_must_use() -> Result<(), ()> {\n unimplemented!();\n}\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = 3;\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0));\nfoo((0));\n((1, 2));\n```" + } + }, + { + "id": "drop_bounds", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for generics with `std::ops::Drop` as bounds.", + "Why is this bad": "`Drop` bounds do not really accomplish anything.\nA type may have compiler-generated drop glue without implementing the\n`Drop` trait itself. The `Drop` trait also only has one method,\n`Drop::drop`, and that function is by fiat not callable in user code.\nSo there is really no use case for using `Drop` in trait bounds.\n\nThe most likely use case of a drop bound is to distinguish between types\nthat have destructors and types that don't. Combined with specialization,\na naive coder would write an implementation that assumed a type could be\ntrivially dropped, then write a specialization for `T: Drop` that actually\ncalls the destructor. Except that doing so is not correct; String, for\nexample, doesn't actually implement Drop, but because String contains a\nVec, assuming it can be trivially dropped will leak memory.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {}\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```ignore\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g., MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // We don't care about zero.\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine() { }\n\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code() { }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too() { }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```no_run\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0,\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nif x + 1 == x + 1 {}\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g., `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\nlet x = 1;\n0 / x;\n0 * x;\nx & 0;\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {\n x = 1;\n 1\n} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet v: f32 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789\n\n// Good\nlet v: f64 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantics of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg));\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str());\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|| panic!(\"Err {}: {}\", err_code, err_msg));\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust,ignore\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n // ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Using `.enumerate()` makes the intent more clear,\ndeclutters the code and may be faster in some instances.", + "Known problems": "None.", + "Example": "```rust\nlet mut i = 0;\nfor item in &v {\n bar(i, *item);\n i += 1;\n}\n```\nCould be written as\n```rust\nfor (i, item) in v.iter().enumerate() { bar(i, *item); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() {\n // ..\n}\n```\ncan be rewritten to\n```rust\nfor x in y {\n // ..\n}\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() {\n // ..\n}\n```\ncan be rewritten to\n```rust\nfor x in &y {\n // ..\n}\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut std::io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\nfn unused_lifetime<'a>(x: u8) {\n // ..\n}\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\nlet vec = vec![1];\nvec.iter().filter(|x| **x == 0).map(|x| *x * 2);\n```" + } + }, + { + "id": "filter_map_next", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter_map(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().filter(|x| **x == 0).next();\n```\nCould be written as\n```rust\nvec.iter().find(|x| **x == 0);\n```" + } + }, + { + "id": "find_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.find(_).map(_)`.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\n (0..3).find(|x| *x == 2).map(|x| x * 2);\n```\nCan be written as\n```rust\n (0..3).find_map(|x| if x == 2 { Some(x * 2) } else { None });\n```" + } + }, + { + "id": "flat_map_identity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `flat_map(|x| x)`.", + "Why is this bad": "Readability, this can be written more concisely by using `flatten`.", + "Known problems": "None", + "Example": "```rust\niter.flat_map(|x| x);\n```\nCan be written as\n```rust\niter.flatten();\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0;\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nlet x = 1.2331f64;\nlet y = 1.2332f64;\nif y == 1.23f64 { }\nif y != x {} // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nlet x: f64 = 1.0;\nconst ONE: f64 = 1.00;\nx == ONE; // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 { 1 }\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 { 1 }\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 {\n 1\n};\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 {\n 1\n};\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```ignore\nfor (k, _) in &map {\n ..\n}\n```\n\ncould be replaced by\n\n```ignore\nfor k in map.keys() {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in option {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Some(x) = option {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in result {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Ok(x) = result {\n ..\n}\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_last_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for using `x.get(x.len() - 1)` instead of\n`x.last()`.", + "Why is this bad": "Using `x.last()` is easier to read and has the same\nresult.\n\nNote that using `x[x.len() - 1]` is semantically different from\n`x.last()`. Indexing into the array will panic on out-of-bounds\naccesses, while `x.get()` and `x.last()` will return `None`.\n\nThere is another lint (get_unwrap) that covers the case of using\n`x.get(index).unwrap()` instead of `x[index]`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet x = vec![2, 3, 5];\nlet last_element = x.get(x.len() - 1);\n\n// Good\nlet x = vec![2, 3, 5];\nlet last_element = x.last();\n```" + } + }, + { + "id": "get_unwrap", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "Not a replacement for error handling: Using either\n`.unwrap()` or the Index trait (`[]`) carries the risk of causing a `panic`\nif the value being accessed is `None`. If the use of `.get().unwrap()` is a\ntemporary placeholder for dealing with the `Option` type, then this does\nnot mitigate the need for error handling. If there is a chance that `.get()`\nwill be `None` in your program, then it is advisable that the `None` case\nis handled in a future refactor instead of using `.unwrap()` or the Index\ntrait.", + "Example": "```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g., `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0;\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```ignore\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```ignore\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nif a == b {\n \u2026\n} else if a == b {\n \u2026\n}\n```\n\nNote that this lint ignores all conditions with a function call as it could\nhave side effects:\n\n```ignore\nif foo() {\n \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (`SipHash`).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { }\n\npub fn foo(map: &mut HashMap) { }\n```\ncould be rewritten as\n```rust\nimpl Serialize for HashMap { }\n\npub fn foo(map: &mut HashMap) { }\n```" + } + }, + { + "id": "implicit_return", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for missing return statements at the end of a block.", + "Why is this bad": "Actually omitting the return keyword is idiomatic Rust code. Programmers\ncoming from other languages might prefer the expressiveness of `return`. It's possible to miss\nthe last returning statement because the only difference is a missing `;`. Especially in bigger\ncode with multiple return paths having a `return` keyword makes it easier to find the\ncorresponding statements.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: usize) -> usize {\n x\n}\n```\nadd return\n```rust\nfn foo(x: usize) -> usize {\n return x;\n}\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 618_64_9189_73_511;\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust,no_run\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { }\n```" + } + }, + { + "id": "inefficient_to_string", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.to_string()` on an `&&T` where\n`T` implements `ToString` directly (like `&&str` or `&&String`).", + "Why is this bad": "This bypasses the specialized implementation of\n`ToString` and instead goes through the more expensive string formatting\nfacilities.", + "Known problems": "None.", + "Example": "```rust\n// Generic implementation for `T: Display` is used (slow)\n[\"foo\", \"bar\"].iter().map(|s| s.to_string());\n\n// OK, the specialized impl is used\n[\"foo\", \"bar\"].iter().map(|&s| s.to_string());\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```no_run\nuse std::iter;\n\niter::repeat(1_u8).collect::>();\n```" + } + }, + { + "id": "inherent_to_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the definition of inherent methods with a signature of `to_string(&self) -> String`.", + "Why is this bad": "This method is also implicitly defined if a type implements the `Display` trait. As the functionality of `Display` is much more versatile, it should be preferred.", + "Known problems": "None", + " Example": "```rust\n// Bad\npub struct A;\n\nimpl A {\n pub fn to_string(&self) -> String {\n \"I am A\".to_string()\n }\n}\n```\n\n```rust\n// Good\nuse std::fmt;\n\npub struct A;\n\nimpl fmt::Display for A {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n write!(f, \"I am A\")\n }\n}\n```" + } + }, + { + "id": "inherent_to_string_shadow_display", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the definition of inherent methods with a signature of `to_string(&self) -> String` and if the type implementing this method also implements the `Display` trait.", + "Why is this bad": "This method is also implicitly defined if a type implements the `Display` trait. The less versatile inherent method will then shadow the implementation introduced by `Display`.", + "Known problems": "None", + " Example": "```rust\n// Bad\nuse std::fmt;\n\npub struct A;\n\nimpl A {\n pub fn to_string(&self) -> String {\n \"I am A\".to_string()\n }\n}\n\nimpl fmt::Display for A {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n write!(f, \"I am A, too\")\n }\n}\n```\n\n```rust\n// Good\nuse std::fmt;\n\npub struct A;\n\nimpl fmt::Display for A {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n write!(f, \"I am A\")\n }\n}\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```ignore\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nif x >= y + 1 {}\n```\n\nCould be written as:\n\n```rust\nif x > y {}\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1;\n```" + } + }, + { + "id": "integer_division", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for division of integers", + "Why is this bad": "When outside of some very specific algorithms,\ninteger division is very often a mistake because it discards the\nremainder.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = 3 / 2;\n println!(\"{}\", x);\n}\n```" + } + }, + { + "id": "into_iter_on_array", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `into_iter` calls on types which should be replaced by `iter` or\n`iter_mut`.", + "Why is this bad": "Arrays and `PathBuf` do not yet have an `into_iter` method which move out\ntheir content into an iterator. Auto-referencing resolves the `into_iter` call to its reference\ninstead, like `<&[T; N] as IntoIterator>::into_iter`, which just iterates over item references\nlike calling `iter` would. Furthermore, when the standard library actually\n[implements the `into_iter` method](https://github.com/rust-lang/rust/issues/25725) which moves\nthe content out of the array, the original use of `into_iter` got inferred with the wrong type\nand the code will be broken.", + "Known problems": "None", + "Example": "```rust\nlet _ = [1, 2, 3].into_iter().map(|x| *x).collect::>();\n```\nCould be written as:\n```rust\nlet _ = [1, 2, 3].iter().map(|x| *x).collect::>();\n```" + } + }, + { + "id": "into_iter_on_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `into_iter` calls on references which should be replaced by `iter`\nor `iter_mut`.", + "Why is this bad": "Readability. Calling `into_iter` on a reference will not move out its\ncontent into the resulting iterator, which is confusing. It is better just call `iter` or\n`iter_mut` directly.", + "Known problems": "None", + "Example": "```rust\nlet _ = (&vec![3, 4, 5]).into_iter();\n```" + } + }, + { + "id": "invalid_ref", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang/rust-clippy/issues/886", + "Example": "```rust\nlet x: u8 = 1;\n(x as u32) > 300;\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```ignore\nfor x in y.next() {\n ..\n}\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```ignore\nfor x in (5..5).step_by(0) {\n ..\n}\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 6186491_8973511;\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a enum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n pub fn len(&self) -> usize {\n ..\n }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```ignore\nif x.len() == 0 {\n ..\n}\nif y.len() != 0 {\n ..\n}\n```\ninstead use\n```ignore\nif x.is_empty() {\n ..\n}\nif !y.is_empty() {\n ..\n}\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = {\n 1;\n};\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x: LinkedList = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```ignore\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "main_recursion", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for recursion using the entrypoint.", + "Why is this bad": "Apart from special setups (which we could detect following attributes like #![no_std]),\nrecursing into main() seems like an unintuitive antipattern we should be able to detect.", + "Known problems": "None.", + "Example": "```no_run\nfn main() {\n main();\n}\n```" + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```\nCould be written as:\n```rust\ndst[64..(src.len() + 64)].clone_from_slice(&src[..]);\n```" + } + }, + { + "id": "manual_mul_add", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for expressions of the form `a * b + c`\nor `c + a * b` where `a`, `b`, `c` are floats and suggests using\n`a.mul_add(b, c)` instead.", + "Why is this bad": "Calculating `a * b + c` may lead to slight\nnumerical inaccuracies as `a * b` is rounded before being added to\n`c`. Depending on the target architecture, `mul_add()` may be more\nperformant.", + "Known problems": "This lint can emit semantic incorrect suggestions.\nFor example, for `a * b * c + d` the suggestion `a * b.mul_add(c, d)`\nis emitted, which is equivalent to `a * (b * c + d)`. (#4735)", + "Example": "```rust\nlet foo = (a * b) + c;\n```\n\ncan be written as\n\n```rust\nlet foo = a.mul_add(b, c);\n```" + } + }, + { + "id": "manual_saturating_arithmetic", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `.checked_add/sub(x).unwrap_or(MAX/MIN)`.", + "Why is this bad": "These can be written simply with `saturating_add/sub` methods.", + "Example": "```rust\nlet add = x.checked_add(y).unwrap_or(u32::max_value());\nlet sub = x.checked_sub(y).unwrap_or(u32::min_value());\n```\n\ncan be written using dedicated methods for saturating addition/subtraction as:\n\n```rust\nlet add = x.saturating_add(y);\nlet sub = x.saturating_sub(y);\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust\nlet mut a = 42;\nlet mut b = 1337;\n\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nlet mut a = 1;\nlet mut b = 2;\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```ignore\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nif !map.contains_key(&k) {\n map.insert(k.clone(), v);\n}\n```", + "Example": "```rust\nif !map.contains_key(&k) {\n map.insert(k, v);\n}\n```\ncan both be rewritten as:\n```rust\nmap.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\nlet vec = vec![vec![1]];\nvec.iter().map(|x| x.iter()).flatten();\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1...10 => println!(\"1 ... 10\"),\n 5...15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust,ignore\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x: Result = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\nlet infinite_iter = 0..;\n[0..].iter().zip(infinite_iter.take_while(|x| *x > 5));\n```" + } + }, + { + "id": "mem_discriminant_non_enum", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `mem::discriminant()` on a non-enum type.", + "Why is this bad": "The value of `mem::discriminant()` on non-enum types\nis unspecified.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nmem::discriminant(&\"hello\");\nmem::discriminant(&&Some(2));\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "mem_replace_with_uninit", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `mem::replace(&mut _, mem::uninitialized())`\nand `mem::replace(&mut _, mem::zeroed())`.", + "Why is this bad": "This will lead to undefined behavior even if the\nvalue is overwritten later, because the uninitialized value may be\nobserved in the case of a panic.", + "Known problems": "None.", + "Example": "```\nuse std::mem;\n# fn may_panic(v: Vec) -> Vec { v }\n\n#[allow(deprecated, invalid_value)]\nfn myfunc (v: &mut Vec) {\n let taken_v = unsafe { mem::replace(v, mem::uninitialized()) };\n let new_v = may_panic(taken_v); // undefined behavior on panic\n mem::forget(mem::replace(v, new_v));\n}\n```\n\nThe [take_mut](https://docs.rs/take_mut) crate offers a sound solution,\nat the cost of either lazily creating a replacement value or aborting\non panic, to ensure that the uninitialized value cannot be observed." + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```ignore\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore, it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\nlet b = 2;\n// ...\na += a + b;\n```" + } + }, + { + "id": "missing_const_for_fn", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Suggests the use of `const` in functions and methods where possible.", + "Why is this bad": "Not having the function const prevents callers of the function from being const as well.", + "Known problems": "Const 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.", + "Example": "```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```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make\nsense. It allows the crate to require all exported methods to be `#[inline]` by default, and\nthen opt out for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn private() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn private() {} // ok\n pub fn not_ptrivate() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "missing_safety_doc", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the doc comments of publicly visible\nunsafe functions and warns if there is no `# Safety` section.", + "Why is this bad": "Unsafe functions should document their safety\npreconditions, so that users can be sure they are using them safely.", + "Known problems": "None.", + "Examples": ":\n```rust\n/// This function should really be documented\npub unsafe fn start_apocalypse(u: &mut Universe) {\n unimplemented!();\n}\n```\n\nAt least write a line about safety:\n\n```rust\n/// # Safety\n///\n/// This function should not be called before the horsemen are ready.\npub unsafe fn start_apocalypse(u: &mut Universe) {\n unimplemented!();\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n suffix is required\n- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32;\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```ignore\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "module_name_repetitions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nlet a = x % 1;\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "must_use_candidate", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for public functions that have no\n[`#[must_use]`] attribute, but return something not already marked\nmust-use, have no mutable arg and mutate no statics.\n\n[`#[must_use]`]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute", + "Why is this bad": "Not bad at all, this lint just shows places where\nyou could add the attribute.", + "Known problems": "The lint only checks the arguments for mutable\ntypes without looking if they are actually changed. On the other hand,\nit also ignores a broad range of potentially interesting side effects,\nbecause we cannot decide whether the programmer intends the function to\nbe called for the side effect or the result. Expect many false\npositives. At least we don't lint if the result type is unit or already\n`#[must_use]`.", + "Examples": "```rust\n// this could be annotated with `#[must_use]`.\nfn id(t: T) -> T { t }\n```" + } + }, + { + "id": "must_use_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for a [`#[must_use]`] attribute on\nunit-returning functions and methods.\n\n[`#[must_use]`]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute", + "Why is this bad": "Unit values are useless. The attribute is likely\na remnant of a refactoring that removed the return type.", + "Known problems": "None.", + "Examples": "```rust\n#[must_use]\nfn useless() { }\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```ignore\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::sync::atomic::AtomicBool` and `std::sync::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::sync::atomic::AtomicUsize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&vec.iter().filter(|x| **x == 0u8).count(); // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we, of course, do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust,ignore\nif x {\n false\n} else {\n true\n}\n```\nCould be written as\n```rust,ignore\n!x\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "None." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust,ignore\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n (&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime mismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\nlet mut v = Vec::::new();\nlet _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.clone().collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n # break;\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n # break;\n}\n```" + } + }, + { + "id": "needless_doctest_main", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `fn main() { .. }` in doctests", + "Why is this bad": "The test can be shorter (and likely more readable)\nif the `fn main()` is left implicit.", + "Known problems": "None.", + "Examples": "``````rust\n/// An example of a doctest with a `main()` function\n///\n/// # Examples\n///\n/// ```\n/// fn main() {\n/// // this needs not be in an `fn`\n/// }\n/// ```\nfn needless_main() {\n unimplemented!();\n}\n``````" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 {\n x\n}\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n```\n\n```rust\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nlet vec = vec!['a', 'b', 'c'];\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```\nCould be written as:\n```rust\nlet vec = vec!['a', 'b', 'c'];\nfor i in vec {\n println!(\"{}\", i);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) -> usize {\n return x;\n}\n```\nsimplify to\n```rust\nfn foo(x: usize) -> usize {\n x\n}\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint {\n x: 1,\n y: 1,\n ..zero_point\n};\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g., `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```ignore\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop {\n ..;\n break;\n}\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).\n\nIt detects both the case when a manual\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\nimplementation is required and also when it can be created with\n`#[derive(Default)]`", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```ignore\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nOr, if\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\ncan be derived by `#[derive(Default)]`:\n\n```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nInstead, use:\n\n```rust\n#[derive(Default)]\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = String::from(\"\u20ac\");\n```\nCould be written as:\n```rust\nlet x = String::from(\"\\u{20ac}\");\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```ignore\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nuse std::fs::OpenOptions;\n\nOpenOptions::new().read(true).truncate(true);\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereference raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) {\n println!(\"{}\", unsafe { *x });\n}\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```ignore\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```ignore\n&x == y\n```" + } + }, + { + "id": "option_and_then_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.and_then(|x| Some(y))`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map(|x| y)`.", + "Known problems": "None", + "Example": "```rust\nlet x = Some(\"foo\");\nlet _ = x.and_then(|s| Some(s.len()));\n```\n\nThe correct use would be:\n\n```rust\nlet x = Some(\"foo\");\nlet _ = x.map(|s| s.len());\n```" + } + }, + { + "id": "option_expect_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.expect()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case. Still,\n for a lot of quick-and-dirty code, `expect` is a good choice, which is why\n this lint is `Allow` by default.", + "Known problems": "None.", + "Example": "Using expect on an `Option`:\n\n```rust\nlet opt = Some(1);\nopt.expect(\"one\");\n```\n\nBetter:\n\n```ignore\nlet opt = Some(1);\nopt?;\n# Some::<()>(())\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```ignore\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)));\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg);\n}\n\nif let Some(msg) = x {\n log_err_msg(format_msg(msg));\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0);\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function);\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}\n```" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "Using unwrap on an `Option`:\n\n```rust\nlet opt = Some(1);\nopt.unwrap();\n```\n\nBetter:\n\n```rust\nlet opt = Some(1);\nopt.expect(\"more helpful message\");\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new());\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new);\n```\nor\n```rust\nfoo.unwrap_or_default();\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```no_run\n# #![allow(const_err)]\nlet x = [1, 2, 3, 4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a;\n```" + } + }, + { + "id": "panic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `panic!`.", + "Why is this bad": "`panic!` will stop the execution of the executable", + "Known problems": "None.", + "Example": "```no_run\npanic!(\"even with a good reason\");\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```no_run\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { true }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "path_buf_push_overwrite", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "* Checks for [push](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.push)\ncalls on `PathBuf` that can cause overwrites.", + "Why is this bad": "Calling `push` with a root path at the start can overwrite the\nprevious defined path.", + "Known problems": "None.", + "Example": "```rust\nuse std::path::PathBuf;\n\nlet mut x = PathBuf::from(\"/foo\");\nx.push(\"/bar\");\nassert_eq!(x, PathBuf::from(\"/bar\"));\n```\nCould be written:\n\n```rust\nuse std::path::PathBuf;\n\nlet mut x = PathBuf::from(\"/foo\");\nx.push(\"bar\");\nassert_eq!(x, PathBuf::from(\"/foo/bar\"));\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```ignore\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.offset(offset as isize);\n}\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.add(offset);\n}\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator.", + "Why is this bad": "Question mark usage is more idiomatic.", + "Known problems": "None", + "Example": "```ignore\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```ignore\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g., `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust,ignore\nfor x..=(y-1) { .. }\n```\nCould be written as\n```rust,ignore\nfor x..y { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g., `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e., `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust,ignore\nfor x..(y+1) { .. }\n```\nCould be written as\n```rust,ignore\nfor x..=y { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len());\n```\nCould be written as\n```rust\nx.iter().enumerate();\n```" + } + }, + { + "id": "redundant_clone", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for a redudant `clone()` (and its relatives) which clones an owned\nvalue that is going to be dropped without further use.", + "Why is this bad": "It is not always possible for the compiler to eliminate useless\nallocations and deallocations generated by redundant `clone()`s.", + "Known problems": "False-negatives: analysis performed by this lint is conservative and limited.", + "Example": "```rust\n{\n let x = Foo::new();\n call(x.clone());\n call(x.clone()); // this can just pass `x`\n}\n\n[\"lorem\", \"ipsum\"].join(\" \").to_string();\n\nPath::new(\"/a/b\").join(\"c\").to_path_buf();\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee rust-lang/rust-clippy#1439 for more details.", + "Example": "```rust,ignore\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust,ignore\n(|| 42)()\n```" + } + }, + { + "id": "redundant_closure_for_method_calls", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for closures which only invoke a method on the closure\nargument and can be replaced by referencing the method directly.", + "Why is this bad": "It's unnecessary to create the closure.", + "Known problems": "rust-lang/rust-clippy#3071, rust-lang/rust-clippy#4002,\nrust-lang/rust-clippy#3942", + "Example": "```rust,ignore\nSome('a').map(|s| s.to_uppercase());\n```\nmay be rewritten as\n```rust,ignore\nSome('a').map(char::to_uppercase);\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```ignore\nlet foo = Foo { bar };\n```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\n\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "redundant_static_lifetimes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants and statics with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```ignore\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```ignore\n const FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n static FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Point(30, 20);\nlet x = (&point).0;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```ignore\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_expect_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.expect()` calls on `Result`s.", + "Why is this bad": "`result.expect()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.", + "Known problems": "None.", + "Example": "Using expect on an `Result`:\n\n```rust\nlet res: Result = Ok(1);\nres.expect(\"one\");\n```\n\nBetter:\n\n```\nlet res: Result = Ok(1);\nres?;\n# Ok::<(), ()>(())\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)));\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg);\n};\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg));\n};\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.ok().map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function);\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "Using unwrap on an `Result`:\n\n```rust\nlet res: Result = Ok(1);\nres.unwrap();\n```\n\nBetter:\n\n```rust\nlet res: Result = Ok(1);\nres.expect(\"more helpful message\");\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```ignore\nfor x in 5..10 - 5 {\n ..\n} // oops, stray `-`\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().find(|x| **x == 0).is_some();\n```\nCould be written as\n```rust\nvec.iter().any(|x| *x == 0);\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = 2;\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet x = 2;\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y;\nlet x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust,ignore\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```ignore\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X {\n ..\n }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```ignore\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g., `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => (),\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with two arms where an `if let else` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "Using `match`:\n\n```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(&other_ref),\n}\n```\n\nUsing `if let` with `else`:\n\n```rust\nif let Some(ref foo) = x {\n bar(foo);\n} else {\n bar(&other_ref);\n}\n```" + } + }, + { + "id": "slow_vector_initialization", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks slow zero-filled vector initialization", + "Why is this bad": "These structures are non-idiomatic and less efficient than simply using\n`vec![0; len]`.", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nvec1.resize(len, 0);\n\nlet mut vec2 = Vec::with_capacity(len);\nvec2.extend(repeat(0).take(len))\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore, some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\";\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def);\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g., `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else`. It lints if the `else`\nis followed immediately by a newline or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} { // looks like an `else` is missing here\n}\n\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\n{ // this is the `else` block of the previous `if`, but should it be?\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `map` followed by a `count`.", + "Why is this bad": "It looks suspicious. Maybe `map` was confused with `filter`.\nIf the `map` call is intentional, this should be rewritten.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).map(|x| x + 2).count();\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "suspicious_unary_op_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks the formatting of a unary operator on the right hand side\nof a binary operator. It lints if there is no space between the binary and unary operators,\nbut there is a space between the unary and its operand.", + "Why is this bad": "This is either a typo in the binary operator or confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo <- 30 { // this should be `foo < -30` but looks like a different operator\n}\n\nif foo &&! bar { // this should be `foo && !bar` but looks like a different operator\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "todo", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `todo!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```no_run\ntodo!();\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n // ..\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "too_many_lines", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions with a large amount of lines.", + "Why is this bad": "Functions with a lot of lines are harder to understand\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.", + "Known problems": "None.", + "Example": "``` rust\nfn im_too_long() {\nprintln!(\"\");\n// ... 100 more LoC\nprintln!(\"\");\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-lines-threshold: u64`: The maximum number of lines a function or method can have (defaults to `100 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g., changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool {\n true\n}\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet b: &[u8] = &[1_u8, 2_u8];\nunsafe {\n let _: &str = std::mem::transmute(b); // where b: &[u8]\n}\n\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet x = 1_u8;\nunsafe {\n let _: bool = std::mem::transmute(x); // where x: u8\n}\n\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet x = 1_u32;\nunsafe {\n let _: char = std::mem::transmute(x); // where x: u32\n}\n\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "Transmutes are dangerous and error-prone, whereas `from_bits` is intuitive\nand safe.", + "Known problems": "None.", + "Example": "```rust\nunsafe {\n let _: f32 = std::mem::transmute(1_u32); // where x: u32\n}\n\n// should be:\nlet _: f32 = f32::from_bits(1_u32);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32;\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust,ignore\nunsafe {\n let _: &T = std::mem::transmute(p); // where p: *const T\n}\n\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "transmuting_null", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmute calls which would receive a null pointer.", + "Why is this bad": "Transmuting a null pointer is undefined behavior.", + "Known problems": "Not all cases can be detected at the moment of this writing.\nFor example, variables which hold a null pointer and are then fed to a `transmute`\ncall, aren't detectable yet.", + "Example": "```rust\nlet null_ref: &u64 = unsafe { std::mem::transmute(0 as *const u64) };\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\n// Bad\nfn foo(v: &u32) {}\n```\n\n```rust\n// Better\nfn foo(v: u32) {}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "try_err", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Err(x)?`.", + "Why is this bad": "The `?` operator is designed to allow calls that\ncan fail to be easily chained. For example, `foo()?.bar()` or\n`foo(bar()?)`. Because `Err(x)?` can't be used that way (it will\nalways return), it is more clear to write `return Err(x)`.", + "Known problems": "None.", + "Example": "```rust\nfn foo(fail: bool) -> Result {\n if fail {\n Err(\"failed\")?;\n }\n Ok(0)\n}\n```\nCould be written:\n\n```rust\nfn foo(fail: bool) -> Result {\n if fail {\n return Err(\"failed\".into());\n }\n Ok(0)\n}\n```" + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "type_repetition_in_bounds", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "This lint warns about unnecessary type repetitions in trait bounds", + "Why is this bad": "Repeating the type for every bound makes the code\nless readable than combining the bounds", + "Example": "```rust\npub fn foo(t: T) where T: Copy, T: Clone {}\n```\n\nCould be written as:\n\n```rust\npub fn foo(t: T) where T: Copy + Clone {}\n```" + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \"a\u0300\"\" and \"\u00e0\"\" aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```no_run\nunimplemented!();\n```" + } + }, + { + "id": "uninit_assumed_init", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `MaybeUninit::uninit().assume_init()`.", + "Why is this bad": "For most types, this is undefined behavior.", + "Known problems": "For now, we accept empty tuples and tuples / arrays\nof `MaybeUninit`. There may be other types that allow uninitialized\ndata, but those are not yet rigorously defined.", + "Example": "```rust\n// Beware the UB\nuse std::mem::MaybeUninit;\n\nlet _: usize = unsafe { MaybeUninit::uninit().assume_init() };\n```\n\nNote that the following is OK:\n\n```rust\nuse std::mem::MaybeUninit;\n\nlet _: [MaybeUninit; 5] = unsafe {\n MaybeUninit::uninit().assume_init()\n};\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a\nunit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit. This includes all binary\ncomparisons (like `==` and `<`) and asserts.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif {\n foo();\n} == {\n bar();\n} {\n baz();\n}\n```\nis equal to\n```rust\n{\n foo();\n bar();\n baz();\n}\n```\n\nFor asserts:\n```rust\nassert_eq!({ foo(); }, { bar(); });\n```\nwill always succeed" + } + }, + { + "id": "unknown_clippy_lints", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `allow`/`warn`/`deny`/`forbid` attributes with scoped clippy\nlints and if those lints exist in clippy. If there is an uppercase letter in the lint name\n(not the tool name) and a lowercase version of this lint exists, it will suggest to lowercase\nthe lint name.", + "Why is this bad": "A lint attribute with a mistyped lint name won't have an effect.", + "Known problems": "None.", + "Example": "Bad:\n```rust\n#![warn(if_not_els)]\n#![deny(clippy::All)]\n```\n\nGood:\n```rust\n#![warn(if_not_else)]\n#![deny(clippy::all)]\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32;\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```ignore\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust,ignore\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "None", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```ignore\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unneeded_wildcard_pattern", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for tuple patterns with a wildcard\npattern (`_`) is next to a rest pattern (`..`).\n\n_NOTE_: While `_, ..` means there is at least one element left, `..`\nmeans there are 0 or more elements left. This can make a difference\nwhen refactoring, but shouldn't result in errors in the refactored code,\nsince the wildcard pattern isn't used anyway.", + "Why is this bad": "The wildcard pattern is unneeded as the rest pattern\ncan match that element as well.", + "Known problems": "None.", + "Example": "```rust\n\nmatch t {\n TupleStruct(0, .., _) => (),\n _ => (),\n}\n```\ncan be written as\n```rust\n\nmatch t {\n TupleStruct(0, ..) => (),\n _ => (),\n}\n```" + } + }, + { + "id": "unreachable", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unreachable!`.", + "Why is this bad": "This macro can cause code to panic", + "Known problems": "None.", + "Example": "```no_run\nunreachable!();\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 61864918973511;\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unsafe_vector_initialization", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unsound_collection_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes between collections whose\ntypes have different ABI, size or alignment.", + "Why is this bad": "This is undefined behavior.", + "Known problems": "Currently, we cannot know whether a type is a\ncollection, so we just lint the ones that come with `std`.", + "Example": "```rust\n// different size, therefore likely out-of-bounds memory access\n// You absolutely do not want this in your code!\nunsafe {\n std::mem::transmute::<_, Vec>(vec![2_u16])\n};\n```\n\nYou must always iterate, map and collect the values:\n\n```rust\nvec![2_u16].into_iter().map(u32::from).collect::>();\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unused_collect", + "group": "deprecated", + "level": "Deprecated", + "docs": {} + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks methods that contain a `self` argument but don't use it", + "Why is this bad": "It may be clearer to define the method as an associated function instead\nof an instance method if it doesn't require `self`.", + "Known problems": "None.", + "Example": "```rust,ignore\nstruct A;\nimpl A {\n fn method(&self) {}\n}\n```\n\nCould be written:\n\n```rust,ignore\nstruct A;\nimpl A {\n fn method() {}\n}\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g., the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () {\n ()\n}\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "- False positive when using associated types (#2843)\n- False positives in some situations when using generics (#3410)", + "Example": "```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```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]`, `#[allow(deprecated)]` and\n`#[allow(unreachable_pub)]` on `use` items and `#[allow(unused_imports)]` on\n`extern crate` items with a `#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```ignore\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"foo\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\");\nformat!(\"{}\", foo);\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust,ignore\ncore::intrinsics::transmute(t); // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "vec_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Vec>` where T: Sized anywhere in the code.", + "Why is this bad": "`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.", + "Known problems": "Vec> makes sense if T is a large type (see #3530,\n1st comment).", + "Example": "```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nif x & 0x1111 == 0 { }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust,no_run\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n };\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n};\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```ignore\nwhile let Some(val) = iter() {\n ..\n}\n```" + } + }, + { + "id": "wildcard_dependencies", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard dependencies in the `Cargo.toml`.", + "Why is this bad": "[As the edition guide says](https://rust-lang-nursery.github.io/edition-guide/rust-2018/cargo-and-crates-io/crates-io-disallows-wildcard-dependencies.html),\nit is highly unlikely that you work with any possible version of your dependency,\nand wildcard dependencies would cause unnecessary breakage in the ecosystem.", + "Known problems": "None.", + "Example": "```toml\n[dependencies]\nregex = \"*\"\n```" + } + }, + { + "id": "wildcard_enum_match_arm", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard enum matches using `_`.", + "Why is this bad": "New enum variants added by library updates can be missed.", + "Known problems": "Suggested replacements may be incorrect if guards exhaustively cover some\nvariants, and also may not use correct path to enum if it's not present in the current scope.", + "Example": "```rust\nmatch x {\n A => {},\n _ => {},\n}\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(buf, \"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl<'a> X {\n pub fn as_str(self) -> &'a str {\n \"foo\"\n }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```ignore\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0;\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\nlet a = 0 as *const u32;\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + } +] \ No newline at end of file diff --git a/rust-1.41.0/index.html b/rust-1.41.0/index.html new file mode 100644 index 000000000000..e11f2eeba3b3 --- /dev/null +++ b/rust-1.41.0/index.html @@ -0,0 +1,277 @@ + + + + + + + ALL the Clippy Lints + + + + + + +
+
+

ALL the Clippy Lints

+
+ + + +
+ + + + +
+
+
+
+

Lint levels

+
+ +
+
+
+
+
+

Lint groups

+
+ +
+
+
+
+
+
+
+ + + + + +
+
+
+
+ +
+
+

+
+ {{lint.id}} + +
+ +
+ {{lint.group}} + + Allow + Warn + Deny + Deprecated + + +
+

+
+ +
    +
  • +

    + {{title}} +

    +
    +
    • +
+
+
+
+ + + Fork me on Github + + + + + + + + + diff --git a/rust-1.41.0/lints.json b/rust-1.41.0/lints.json new file mode 100644 index 000000000000..fa3c8a93e4dc --- /dev/null +++ b/rust-1.41.0/lints.json @@ -0,0 +1,3873 @@ +[ + { + "id": "absurd_extreme_comparisons", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons where one side of the relation is\neither the minimum or maximum value for its type and warns if it involves a\ncase that is always true or always false. Only integer and boolean types are\nchecked.", + "Why is this bad": "An expression like `min <= x` may misleadingly imply\nthat it is possible for `x` to be less than the minimum. Expressions like\n`max < x` are probably mistakes.", + "Known problems": "For `usize` the size of the current compile target will\nbe assumed (e.g., 64 bits on 64 bit systems). This means code that uses such\na comparison to detect target pointer width will trigger this lint. One can\nuse `mem::sizeof` and compare its value or conditional compilation\nattributes\nlike `#[cfg(target_pointer_width = \"64\")] ..` instead.", + "Example": "```rust\nlet vec: Vec = vec![];\nif vec.len() <= 0 {}\nif 100 > std::i32::MAX {}\n```" + } + }, + { + "id": "almost_swapped", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `foo = bar; bar = foo` sequences.", + "Why is this bad": "This looks like a failed attempt to swap.", + "Known problems": "None.", + "Example": "```rust\na = b;\nb = a;\n```\nCould be written as:\n```rust\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "approx_constant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Usually, 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).", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet x = 3.14;\nlet y = 1_f64 / x;\n\n// Good\nlet x = std::f32::consts::PI;\nlet y = std::f64::consts::FRAC_1_PI;\n```" + } + }, + { + "id": "as_conversions", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `as` conversions.", + "Why is this bad": "`as` conversions will perform many kinds of\nconversions, including silently lossy conversions and dangerous coercions.\nThere are cases when it makes sense to use `as`, so the lint is\nAllow by default.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a: u32;\n...\nf(a as u16);\n```\n\nUsually better represents the semantics you expect:\n```rust,ignore\nf(a.try_into()?);\n```\nor\n```rust,ignore\nf(a.try_into().expect(\"Unexpected u16 overflow in f\"));\n```" + } + }, + { + "id": "assertions_on_constants", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `assert!(true)` and `assert!(false)` calls.", + "Why is this bad": "Will be optimized out by the compiler or should probably be replaced by a\npanic!() or unreachable!()", + "Known problems": "None", + "Example": "```rust,ignore\nassert!(false)\n// or\nassert!(true)\n// or\nconst B: bool = false;\nassert!(B)\n```" + } + }, + { + "id": "assign_op_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `a = a op b` or `a = b commutative_op a`\npatterns.", + "Why is this bad": "These can be written as the shorter `a op= b`.", + "Known problems": "While forbidden by the spec, `OpAssign` traits may have\nimplementations that differ from the regular `Op` impl.", + "Example": "```rust\nlet mut a = 5;\nlet b = 0;\n// ...\na = a + b;\n```" + } + }, + { + "id": "assign_ops", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint is too subjective, not having a good reason for being in clippy.\nAdditionally, compound assignment operators may be overloaded separately from their non-assigning\ncounterparts, so this lint may suggest a change in behavior or the code may not compile." + } + }, + { + "id": "bad_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for incompatible bit masks in comparisons.\n\nThe formula for detecting if an expression of the type `_ m\n c` (where `` is one of {`&`, `|`} and `` is one of\n{`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following\ntable:\n\n|Comparison |Bit Op|Example |is always|Formula |\n|------------|------|------------|---------|----------------------|\n|`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |\n|`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |\n|`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |\n|`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |\n|`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |\n|`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |", + "Why is this bad": "If the bits that the comparison cares about are always\nset to zero or one by the bit mask, the comparison is constant `true` or\n`false` (depending on mask, compared value, and operators).\n\nSo the code is actively misleading, and the only reason someone would write\nthis intentionally is to win an underhanded Rust contest or create a\ntest-case for this lint.", + "Known problems": "None.", + "Example": "```rust\nif (x & 1 == 2) { }\n```" + } + }, + { + "id": "blacklisted_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of blacklisted names for variables, such\nas `foo`.", + "Why is this bad": "These names are usually placeholder names and should be\navoided.", + "Known problems": "None.", + "Example": "```rust\nlet foo = 3.14;\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `blacklisted-names: Vec`: The list of blacklisted names to lint about (defaults to `[\"foo\", \"bar\", \"baz\", \"quux\"] `)." + } + }, + { + "id": "block_in_if_condition_expr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks to contain an\nexpression.", + "Why is this bad": "It isn't really Rust style, same as using parentheses\nto contain expressions.", + "Known problems": "None.", + "Example": "```rust\nif { true } { /* ... */ }\n```" + } + }, + { + "id": "block_in_if_condition_stmt", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `if` conditions that use blocks containing\nstatements, or conditions that use closures with blocks.", + "Why is this bad": "Using blocks in the condition makes it hard to read.", + "Known problems": "None.", + "Example": "```ignore\nif { let x = somefunc(); x } {}\n// or\nif somefunc(|x| { x == 47 }) {}\n```" + } + }, + { + "id": "bool_comparison", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `x == true`,\n`x != true` and order comparisons such as `x < true` (or vice versa) and\nsuggest using the variable directly.", + "Why is this bad": "Unnecessary code.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x == true {} // could be `if x { }`\n```" + } + }, + { + "id": "borrow_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks if `const` items which is interior mutable (e.g.,\ncontains a `Cell`, `Mutex`, `AtomicXxxx`, etc.) has been borrowed directly.", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` value should be stored inside a `static` item.", + "Known problems": "None", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\n\n// Bad.\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = CONST_ATOM;\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "borrowed_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `&Box` anywhere in the code.", + "Why is this bad": "Any `&Box` can also be a `&T`, which is more\ngeneral.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn foo(bar: &Box) { ... }\n```\n\nBetter:\n\n```rust,ignore\nfn foo(bar: &T) { ... }\n```" + } + }, + { + "id": "box_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Box>` anywhere in the code.", + "Why is this bad": "`Vec` already keeps its contents in a separate area on\nthe heap. So if you `Box` it, you just add another level of indirection\nwithout any benefit whatsoever.", + "Known problems": "None.", + "Example": "```rust,ignore\nstruct X {\n values: Box>,\n}\n```\n\nBetter:\n\n```rust,ignore\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "boxed_local", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `Box` where an unboxed `T` would\nwork fine.", + "Why is this bad": "This is an unnecessary allocation, and bad for\nperformance. It is only necessary to allocate if you wish to move the box\ninto something.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nfoo(*x);\nprintln!(\"{}\", *x);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-large-for-stack: u64`: The maximum size of objects (in bytes) that will be linted. Larger objects are ok on the heap (defaults to `200 `)." + } + }, + { + "id": "builtin_type_shadow", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a generic shadows a built-in type.", + "Why is this bad": "This gives surprising type errors.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn impl_func(&self) -> u32 {\n 42\n }\n}\n```" + } + }, + { + "id": "cargo_common_metadata", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks 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", + "Why is this bad": "It will be more difficult for users to discover the\npurpose of the crate, and key information related to it.", + "Known problems": "None.", + "Example": "```toml\n# This `Cargo.toml` is missing an authors field:\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```" + } + }, + { + "id": "cast_lossless", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts between numerical types that may\nbe replaced by safe conversion functions.", + "Why is this bad": "Rust's `as` keyword will perform many kinds of\nconversions, including silently lossy conversions. Conversion functions such\nas `i32::from` will only perform lossless conversions. Using the conversion\nfunctions prevents conversions from turning into silent lossy conversions if\nthe types of the input expressions ever change, and make it easier for\npeople reading the code to know that the conversion is lossless.", + "Known problems": "None.", + "Example": "```rust\nfn as_u64(x: u8) -> u64 {\n x as u64\n}\n```\n\nUsing `::from` would look like this:\n\n```rust\nfn as_u64(x: u8) -> u64 {\n u64::from(x)\n}\n```" + } + }, + { + "id": "cast_possible_truncation", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts between numerical types that may\ntruncate large values. This is expected behavior, so the cast is `Allow` by\ndefault.", + "Why is this bad": "In some problem domains, it is good practice to avoid\ntruncation. This lint can be activated to help assess where additional\nchecks could be beneficial.", + "Known problems": "None.", + "Example": "```rust\nfn as_u8(x: u64) -> u8 {\n x as u8\n}\n```" + } + }, + { + "id": "cast_possible_wrap", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from an unsigned type to a signed type of\nthe same size. Performing such a cast is a 'no-op' for the compiler,\ni.e., nothing is changed at the bit level, and the binary representation of\nthe value is reinterpreted. This can cause wrapping if the value is too big\nfor the target signed type. However, the cast works as defined, so this lint\nis `Allow` by default.", + "Why is this bad": "While such a cast is not bad in itself, the results can\nbe surprising when this is not the intended behavior, as demonstrated by the\nexample below.", + "Known problems": "None.", + "Example": "```rust\nstd::u32::MAX as i32; // will yield a value of `-1`\n```" + } + }, + { + "id": "cast_precision_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from any numerical to a float type where\nthe receiving type cannot store all values from the original type without\nrounding errors. This possible rounding is to be expected, so this lint is\n`Allow` by default.\n\nBasically, this warns on casting any integer with 32 or more bits to `f32`\nor any 64-bit integer to `f64`.", + "Why is this bad": "It's not bad at all. But in some applications it can be\nhelpful to know where precision loss can take place. This lint can help find\nthose places in the code.", + "Known problems": "None.", + "Example": "```rust\nlet x = std::u64::MAX;\nx as f64;\n```" + } + }, + { + "id": "cast_ptr_alignment", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts from a less-strictly-aligned pointer to a\nmore-strictly-aligned pointer", + "Why is this bad": "Dereferencing the resulting pointer may be undefined\nbehavior.", + "Known problems": "Using `std::ptr::read_unaligned` and `std::ptr::write_unaligned` or similar\non the resulting pointer is fine.", + "Example": "```rust\nlet _ = (&1u8 as *const u8) as *const u16;\nlet _ = (&mut 1u8 as *mut u8) as *mut u16;\n```" + } + }, + { + "id": "cast_ref_to_mut", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for casts of `&T` to `&mut T` anywhere in the code.", + "Why is this bad": "It\u2019s basically guaranteed to be undefined behaviour.\n`UnsafeCell` is the only way to obtain aliasable data that is considered\nmutable.", + "Known problems": "None.", + "Example": "```rust,ignore\nfn x(r: &i32) {\n unsafe {\n *(r as *const _ as *mut _) += 1;\n }\n}\n```\n\nInstead consider using interior mutability types.\n\n```rust\nuse std::cell::UnsafeCell;\n\nfn x(r: &UnsafeCell) {\n unsafe {\n *r.get() += 1;\n }\n}\n```" + } + }, + { + "id": "cast_sign_loss", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for casts from a signed to an unsigned numerical\ntype. In this case, negative values wrap around to large positive values,\nwhich can be quite surprising in practice. However, as the cast works as\ndefined, this lint is `Allow` by default.", + "Why is this bad": "Possibly surprising results. You can activate this lint\nas a one-time check to see where numerical wrapping can arise.", + "Known problems": "None.", + "Example": "```rust\nlet y: i8 = -1;\ny as u128; // will return 18446744073709551615\n```" + } + }, + { + "id": "char_lit_as_u8", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions where a character literal is cast\nto `u8` and suggests using a byte literal instead.", + "Why is this bad": "In general, casting values to smaller types is\nerror-prone and should be avoided where possible. In the particular case of\nconverting a character literal to u8, it is easy to avoid by just using a\nbyte literal instead. As an added bonus, `b'a'` is even slightly shorter\nthan `'a' as u8`.", + "Known problems": "None.", + "Example": "```rust,ignore\n'x' as u8\n```\n\nA better version, using the byte literal:\n\n```rust,ignore\nb'x'\n```" + } + }, + { + "id": "chars_last_cmp", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().last()` or\n`.chars().next_back()` on a `str` to check if it ends with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.ends_with(_)`.", + "Known problems": "None.", + "Example": "```ignore\nname.chars().last() == Some('_') || name.chars().next_back() == Some('-')\n```" + } + }, + { + "id": "chars_next_cmp", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.chars().next()` on a `str` to check\nif it starts with a given char.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.starts_with(_)`.", + "Known problems": "None.", + "Example": "```rust\nlet name = \"foo\";\nif name.chars().next() == Some('_') {};\n```\nCould be written as\n```rust\nlet name = \"foo\";\nif name.starts_with('_') {};\n```" + } + }, + { + "id": "checked_conversions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit bounds checking when casting.", + "Why is this bad": "Reduces the readability of statements & is error prone.", + "Known problems": "None.", + "Example": "```rust\nfoo <= i32::max_value() as u32\n```\n\nCould be written:\n\n```rust\ni32::try_from(foo).is_ok()\n```" + } + }, + { + "id": "clone_double_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for usage of `.clone()` on an `&&T`.", + "Why is this bad": "Cloning an `&&T` copies the inner `&T`, instead of\ncloning the underlying `T`.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = vec![1];\n let y = &&x;\n let z = y.clone();\n println!(\"{:p} {:p}\", *y, z); // prints out the same pointer\n}\n```" + } + }, + { + "id": "clone_on_copy", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.clone()` on a `Copy` type.", + "Why is this bad": "The only reason `Copy` types implement `Clone` is for\ngenerics, not for using the `clone` method on a concrete type.", + "Known problems": "None.", + "Example": "```rust\n42u64.clone();\n```" + } + }, + { + "id": "clone_on_ref_ptr", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `.clone()` on a ref-counted pointer,\n(`Rc`, `Arc`, `rc::Weak`, or `sync::Weak`), and suggests calling Clone via unified\nfunction syntax instead (e.g., `Rc::clone(foo)`).", + "Why is this bad": "Calling '.clone()' on an Rc, Arc, or Weak\ncan obscure the fact that only the pointer is being cloned, not the underlying\ndata.", + "Example": "```rust\nlet x = Rc::new(1);\nx.clone();\n```" + } + }, + { + "id": "cmp_nan", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to NaN.", + "Why is this bad": "NaN does not compare meaningfully to anything \u2013 not\neven itself \u2013 so those comparisons are simply wrong.", + "Known problems": "None.", + "Example": "```rust\n\nif x == NAN { }\n```" + } + }, + { + "id": "cmp_null", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for equality comparisons with `ptr::null`", + "Why is this bad": "It's easier and more readable to use the inherent\n`.is_null()`\nmethod instead", + "Known problems": "None.", + "Example": "```ignore\nif x == ptr::null {\n ..\n}\n```" + } + }, + { + "id": "cmp_owned", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for conversions to owned values just for the sake\nof a comparison.", + "Why is this bad": "The comparison can operate on a reference, so creating\nan owned value effectively throws it away directly afterwards, which is\nneedlessly consuming code and heap space.", + "Known problems": "None.", + "Example": "```rust\nif x.to_owned() == y {}\n```\nCould be written as\n```rust\nif x == y {}\n```" + } + }, + { + "id": "cognitive_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with high cognitive complexity.", + "Why is this bad": "Methods of high cognitive complexity tend to be hard to\nboth read and maintain. Also LLVM will tend to optimize small methods better.", + "Known problems": "Sometimes it's hard to find a way to reduce the\ncomplexity.", + "Example": "No. You'll see it when you get the warning.", + "Configuration": "This lint has the following configuration variables:\n\n* `cognitive-complexity-threshold: u64`: The maximum cognitive complexity a function can have (defaults to `25 `)." + } + }, + { + "id": "collapsible_if", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for nested `if` statements which can be collapsed\nby `&&`-combining their conditions and for `else { if ... }` expressions\nthat\ncan be collapsed to `else if ...`.", + "Why is this bad": "Each `if`-statement adds one level of nesting, which\nmakes code look more complex than it really is.", + "Known problems": "None.", + "Example": "```rust,ignore\nif x {\n if y {\n \u2026\n }\n}\n\n// or\n\nif x {\n \u2026\n} else {\n if y {\n \u2026\n }\n}\n```\n\nShould be written:\n\n```rust.ignore\nif x && y {\n \u2026\n}\n\n// or\n\nif x {\n \u2026\n} else if y {\n \u2026\n}\n```" + } + }, + { + "id": "comparison_chain", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks comparison chains written with `if` that can be\nrewritten with `match` and `cmp`.", + "Why is this bad": "`if` is not guaranteed to be exhaustive and conditionals can get\nrepetitive", + "Known problems": "None.", + "Example": "```rust,ignore\nfn f(x: u8, y: u8) {\n if x > y {\n a()\n } else if x < y {\n b()\n } else {\n c()\n }\n}\n```\n\nCould be written:\n\n```rust,ignore\nuse std::cmp::Ordering;\nfn f(x: u8, y: u8) {\n match x.cmp(&y) {\n Ordering::Greater => a(),\n Ordering::Less => b(),\n Ordering::Equal => c()\n }\n}\n```" + } + }, + { + "id": "copy_iterator", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for types that implement `Copy` as well as\n`Iterator`.", + "Why is this bad": "Implicit copies can be confusing when working with\niterator combinators.", + "Known problems": "None.", + "Example": "```rust,ignore\n#[derive(Copy, Clone)]\nstruct Countdown(u8);\n\nimpl Iterator for Countdown {\n // ...\n}\n\nlet a: Vec<_> = my_iterator.take(1).collect();\nlet b: Vec<_> = my_iterator.collect();\n```" + } + }, + { + "id": "crosspointer_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes between a type `T` and `*T`.", + "Why is this bad": "It's easy to mistakenly transmute between a type and a\npointer to that type.", + "Known problems": "None.", + "Example": "```rust,ignore\ncore::intrinsics::transmute(t) // where the result type is the same as\n // `*t` or `&t`'s\n```" + } + }, + { + "id": "dbg_macro", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of dbg!() macro.", + "Why is this bad": "`dbg!` macro is intended as a debugging tool. It\nshould not be in version control.", + "Known problems": "None.", + "Example": "```rust,ignore\n// Bad\ndbg!(true)\n\n// Good\ntrue\n```" + } + }, + { + "id": "debug_assert_with_mut_call", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for function/method calls with a mutable\nparameter in `debug_assert!`, `debug_assert_eq!` and `debug_assert_ne!` macros.", + "Why is this bad": "In release builds `debug_assert!` macros are optimized out by the\ncompiler.\nTherefore mutating something in a `debug_assert!` macro results in different behaviour\nbetween a release and debug build.", + "Known problems": "None", + "Example": "```rust,ignore\ndebug_assert_eq!(vec![3].pop(), Some(3));\n// or\nfn take_a_mut_parameter(_: &mut u32) -> bool { unimplemented!() }\ndebug_assert!(take_a_mut_parameter(&mut 5));\n```" + } + }, + { + "id": "decimal_literal_representation", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is a better representation for a numeric literal.", + "Why is this bad": "Especially for big powers of 2 a hexadecimal representation is more\nreadable than a decimal representation.", + "Known problems": "None.", + "Example": "`255` => `0xFF`\n`65_535` => `0xFFFF`\n`4_042_322_160` => `0xF0F0_F0F0`", + "Configuration": "This lint has the following configuration variables:\n\n* `literal-representation-threshold: u64`: The lower bound for linting decimal literals (defaults to `16384 `)." + } + }, + { + "id": "declare_interior_mutable_const", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for declaration of `const` items which is interior\nmutable (e.g., contains a `Cell`, `Mutex`, `AtomicXxxx`, etc.).", + "Why is this bad": "Consts are copied everywhere they are referenced, i.e.,\nevery time you refer to the const a fresh instance of the `Cell` or `Mutex`\nor `AtomicXxxx` will be created, which defeats the whole purpose of using\nthese types in the first place.\n\nThe `const` should better be replaced by a `static` item if a global\nvariable is wanted, or replaced by a `const fn` if a constructor is wanted.", + "Known problems": "A \"non-constant\" const item is a legacy way to supply an\ninitialized value to downstream `static` items (e.g., the\n`std::sync::ONCE_INIT` constant). In this case the use of `const` is legit,\nand this lint should be suppressed.", + "Example": "```rust\nuse std::sync::atomic::{AtomicUsize, Ordering::SeqCst};\n\n// Bad.\nconst CONST_ATOM: AtomicUsize = AtomicUsize::new(12);\nCONST_ATOM.store(6, SeqCst); // the content of the atomic is unchanged\nassert_eq!(CONST_ATOM.load(SeqCst), 12); // because the CONST_ATOM in these lines are distinct\n\n// Good.\nstatic STATIC_ATOM: AtomicUsize = AtomicUsize::new(15);\nSTATIC_ATOM.store(9, SeqCst);\nassert_eq!(STATIC_ATOM.load(SeqCst), 9); // use a `static` item to refer to the same instance\n```" + } + }, + { + "id": "default_trait_access", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for literal calls to `Default::default()`.", + "Why is this bad": "It's more clear to the reader to use the name of the type whose default is\nbeing gotten than the generic `Default`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet s: String = Default::default();\n\n// Good\nlet s = String::default();\n```" + } + }, + { + "id": "deprecated_cfg_attr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `#[cfg_attr(rustfmt, rustfmt_skip)]` and suggests to replace it\nwith `#[rustfmt::skip]`.", + "Why is this bad": "Since 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.", + "Known problems": "This 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)", + "Example": "Bad:\n```rust\n#[cfg_attr(rustfmt, rustfmt_skip)]\nfn main() { }\n```\n\nGood:\n```rust\n#[rustfmt::skip]\nfn main() { }\n```" + } + }, + { + "id": "deprecated_semver", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[deprecated]` annotations with a `since`\nfield that is not a valid semantic version.", + "Why is this bad": "For checking the version of the deprecation, it must be\na valid semver. Failing that, the contained information is useless.", + "Known problems": "None.", + "Example": "```rust\n#[deprecated(since = \"forever\")]\nfn something_else() { /* ... */ }\n```" + } + }, + { + "id": "deref_addrof", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `*&` and `*&mut` in expressions.", + "Why is this bad": "Immediately dereferencing a reference is no-op and\nmakes the code less clear.", + "Known problems": "Multiple dereference/addrof pairs are not handled so\nthe suggested fix for `x = **&&y` is `x = *&y`, which is still incorrect.", + "Example": "```rust,ignore\nlet a = f(*&mut b);\nlet c = *&d;\n```" + } + }, + { + "id": "derive_hash_xor_eq", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for deriving `Hash` but implementing `PartialEq`\nexplicitly or vice versa.", + "Why is this bad": "The implementation of these traits must agree (for\nexample for use with `HashMap`) so it\u2019s probably a bad idea to use a\ndefault-generated `Hash` implementation with an explicitly defined\n`PartialEq`. In particular, the following must hold for any type:\n\n```text\nk1 == k2 \u21d2 hash(k1) == hash(k2)\n```", + "Known problems": "None.", + "Example": "```ignore\n#[derive(Hash)]\nstruct Foo;\n\nimpl PartialEq for Foo {\n ...\n}\n```" + } + }, + { + "id": "diverging_sub_expression", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for diverging calls that are not match arms or\nstatements.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Someone might want to use `some_bool || panic!()` as a\nshorthand.", + "Example": "```rust,no_run\nlet a = b() || panic!() || c();\n// `c()` is dead, `panic!()` is only called if `b()` returns `false`\nlet x = (a, b, c, panic!());\n// can simply be replaced by `panic!()`\n```" + } + }, + { + "id": "doc_markdown", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the presence of `_`, `::` or camel-case words\noutside ticks in documentation.", + "Why is this bad": "*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.", + "Known problems": "Lots of bad docs won\u2019t be fixed, what the lint checks\nfor is limited, and there are still false positives.", + "Examples": "```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```", + "Configuration": "This lint has the following configuration variables:\n\n* `doc-valid-idents: Vec`: The list of words this lint should not consider as identifiers needing ticks (defaults to `[\n \"KiB\", \"MiB\", \"GiB\", \"TiB\", \"PiB\", \"EiB\",\n \"DirectX\",\n \"ECMAScript\",\n \"GPLv2\", \"GPLv3\",\n \"GitHub\", \"GitLab\",\n \"IPv4\", \"IPv6\",\n \"JavaScript\",\n \"NaN\", \"NaNs\",\n \"OAuth\",\n \"OpenGL\", \"OpenSSH\", \"OpenSSL\", \"OpenStreetMap\",\n \"TrueType\",\n \"iOS\", \"macOS\",\n \"TeX\", \"LaTeX\", \"BibTeX\", \"BibLaTeX\",\n \"MinGW\",\n \"CamelCase\",\n ] `)." + } + }, + { + "id": "double_comparisons", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for double comparisons that could be simplified to a single expression.", + "Why is this bad": "Readability.", + "Known problems": "None.", + "Example": "```rust\nif x == y || x < y {}\n```\n\nCould be written as:\n\n```rust\nif x <= y {}\n```" + } + }, + { + "id": "double_must_use", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for a [`#[must_use]`] attribute without\nfurther information on functions and methods that return a type already\nmarked as `#[must_use]`.\n\n[`#[must_use]`]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute", + "Why is this bad": "The attribute isn't needed. Not using the result\nwill already be reported. Alternatively, one can add some text to the\nattribute to improve the lint message.", + "Known problems": "None.", + "Examples": "```rust\n#[must_use]\nfn double_must_use() -> Result<(), ()> {\n unimplemented!();\n}\n```" + } + }, + { + "id": "double_neg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects expressions of the form `--x`.", + "Why is this bad": "It can mislead C/C++ programmers to think `x` was\ndecremented.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = 3;\n--x;\n```" + } + }, + { + "id": "double_parens", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unnecessary double parentheses.", + "Why is this bad": "This makes code harder to read and might indicate a\nmistake.", + "Known problems": "None.", + "Example": "```rust\n((0));\nfoo((0));\n((1, 2));\n```" + } + }, + { + "id": "drop_bounds", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for generics with `std::ops::Drop` as bounds.", + "Why is this bad": "`Drop` bounds do not really accomplish anything.\nA type may have compiler-generated drop glue without implementing the\n`Drop` trait itself. The `Drop` trait also only has one method,\n`Drop::drop`, and that function is by fiat not callable in user code.\nSo there is really no use case for using `Drop` in trait bounds.\n\nThe most likely use case of a drop bound is to distinguish between types\nthat have destructors and types that don't. Combined with specialization,\na naive coder would write an implementation that assumed a type could be\ntrivially dropped, then write a specialization for `T: Drop` that actually\ncalls the destructor. Except that doing so is not correct; String, for\nexample, doesn't actually implement Drop, but because String contains a\nVec, assuming it can be trivially dropped will leak memory.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {}\n```" + } + }, + { + "id": "drop_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a value\nthat derives the Copy trait", + "Why is this bad": "Calling `std::mem::drop` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html), since the\nvalue will be copied and moved into the function on invocation.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::drop(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "drop_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::drop` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `drop` on a reference will only drop the\nreference itself, which is a no-op. It will not call the `drop` method (from\nthe `Drop` trait implementation) on the underlying referenced value, which\nis likely what was intended.", + "Known problems": "None.", + "Example": "```ignore\nlet mut lock_guard = mutex.lock();\nstd::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex\n// still locked\noperation_that_requires_mutex_to_be_unlocked();\n```" + } + }, + { + "id": "duplicate_underscore_argument", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments having the similar names\ndiffering by an underscore.", + "Why is this bad": "It affects code readability.", + "Known problems": "None.", + "Example": "```rust\nfn foo(a: i32, _a: i32) {}\n```" + } + }, + { + "id": "duration_subsec", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calculation of subsecond microseconds or milliseconds\nfrom other `Duration` methods.", + "Why is this bad": "It's more concise to call `Duration::subsec_micros()` or\n`Duration::subsec_millis()` than to calculate them.", + "Known problems": "None.", + "Example": "```rust\nlet dur = Duration::new(5, 0);\nlet _micros = dur.subsec_nanos() / 1_000;\nlet _millis = dur.subsec_nanos() / 1_000_000;\n```" + } + }, + { + "id": "else_if_without_else", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of if expressions with an `else if` branch,\nbut without a final `else` branch.", + "Why is this bad": "Some coding guidelines require this (e.g., MISRA-C:2004 Rule 14.10).", + "Known problems": "None.", + "Example": "```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n}\n```\n\nCould be written:\n\n```rust\nif x.is_positive() {\n a();\n} else if x.is_negative() {\n b();\n} else {\n // We don't care about zero.\n}\n```" + } + }, + { + "id": "empty_enum", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `enum`s with no variants.", + "Why is this bad": "Enum's with no variants should be replaced with `!`,\nthe uninhabited type,\nor a wrapper around it.", + "Known problems": "None.", + "Example": "```rust\nenum Test {}\n```" + } + }, + { + "id": "empty_line_after_outer_attr", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for empty lines after outer attributes", + "Why is this bad": "Most likely the attribute was meant to be an inner attribute using a '!'.\nIf it was meant to be an outer attribute, then the following item\nshould not be separated by empty lines.", + "Known problems": "Can cause false positives.\n\nFrom the clippy side it's difficult to detect empty lines between an attributes and the\nfollowing item because empty lines and comments are not part of the AST. The parsing\ncurrently works for basic cases but is not perfect.", + "Example": "```rust\n// Good (as inner attribute)\n#![inline(always)]\n\nfn this_is_fine() { }\n\n// Bad\n#[inline(always)]\n\nfn not_quite_good_code() { }\n\n// Good (as outer attribute)\n#[inline(always)]\nfn this_is_fine_too() { }\n```" + } + }, + { + "id": "empty_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for empty `loop` expressions.", + "Why is this bad": "Those busy loops burn CPU cycles without doing\nanything. Think of the environment and either block on something or at least\nmake the thread sleep for some microseconds.", + "Known problems": "None.", + "Example": "```no_run\nloop {}\n```" + } + }, + { + "id": "enum_clike_unportable_variant", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for C-like enumerations that are\n`repr(isize/usize)` and have values that don't fit into an `i32`.", + "Why is this bad": "This will truncate the variant value on 32 bit\narchitectures, but works fine on 64 bit.", + "Known problems": "None.", + "Example": "```rust\n#[repr(usize)]\nenum NonPortable {\n X = 0x1_0000_0000,\n Y = 0,\n}\n```" + } + }, + { + "id": "enum_glob_use", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `use Enum::*`.", + "Why is this bad": "It is usually better style to use the prefixed name of\nan enumeration variant, rather than importing variants.", + "Known problems": "Old-style enumerations that prefix the variants are\nstill around.", + "Example": "```rust\nuse std::cmp::Ordering::*;\n```" + } + }, + { + "id": "enum_variant_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-name-threshold: u64`: The minimum number of enum variants for the lints about variant names to trigger (defaults to `3 `)." + } + }, + { + "id": "eq_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for equal operands to comparison, logical and\nbitwise, difference and division binary operators (`==`, `>`, etc., `&&`,\n`||`, `&`, `|`, `^`, `-` and `/`).", + "Why is this bad": "This is usually just a typo or a copy and paste error.", + "Known problems": "False negatives: We had some false positives regarding\ncalls (notably [racer](https://github.com/phildawes/racer) had one instance\nof `x.pop() && x.pop()`), so we removed matching any function or method\ncalls. We may introduce a whitelist of known pure functions in the future.", + "Example": "```rust\nif x + 1 == x + 1 {}\n```" + } + }, + { + "id": "erasing_op", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for erasing operations, e.g., `x * 0`.", + "Why is this bad": "The whole expression can be replaced by zero.\nThis is most likely not the intended outcome and should probably be\ncorrected", + "Known problems": "None.", + "Example": "```rust\nlet x = 1;\n0 / x;\n0 * x;\nx & 0;\n```" + } + }, + { + "id": "eval_order_dependence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.", + "Why is this bad": "It is often confusing to read. In addition, the\nsub-expression evaluation order for Rust is not well documented.", + "Known problems": "Code which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.", + "Example": "```rust\nlet mut x = 0;\nlet a = {\n x = 1;\n 1\n} + x;\n// Unclear whether a is 1 or 2.\n```" + } + }, + { + "id": "excessive_precision", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for float literals with a precision greater\nthan that supported by the underlying type", + "Why is this bad": "Rust will truncate the literal silently.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet v: f32 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789\n\n// Good\nlet v: f64 = 0.123_456_789_9;\nprintln!(\"{}\", v); // 0.123_456_789_9\n```" + } + }, + { + "id": "exit", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "`exit()` terminates the program and doesn't provide a\nstack trace.", + "Why is this bad": "Ideally a program is terminated by finishing\nthe main function.", + "Known problems": "None.", + "Example": "```ignore\nstd::process::exit(0)\n```" + } + }, + { + "id": "expect_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.expect(&format!(...))`, `.expect(foo(..))`,\netc., and suggests to use `unwrap_or_else` instead", + "Why is this bad": "The function will always be called.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantics of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.expect(&format!(\"Err {}: {}\", err_code, err_msg));\n```\nor\n```rust\nfoo.expect(format!(\"Err {}: {}\", err_code, err_msg).as_str());\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(|| panic!(\"Err {}: {}\", err_code, err_msg));\n```" + } + }, + { + "id": "expl_impl_clone_on_copy", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for explicit `Clone` implementations for `Copy`\ntypes.", + "Why is this bad": "To avoid surprising behaviour, these traits should\nagree and the behaviour of `Copy` cannot be overridden. In almost all\nsituations a `Copy` type should have a `Clone` implementation that does\nnothing more than copy the object, which is what `#[derive(Copy, Clone)]`\ngets you.", + "Known problems": "Bounds of generic types are sometimes wrong: https://github.com/rust-lang/rust/issues/26925", + "Example": "```rust,ignore\n#[derive(Copy)]\nstruct Foo;\n\nimpl Clone for Foo {\n // ..\n}\n```" + } + }, + { + "id": "explicit_counter_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks `for` loops over slices with an explicit counter\nand suggests the use of `.enumerate()`.", + "Why is it bad": "Using `.enumerate()` makes the intent more clear,\ndeclutters the code and may be faster in some instances.", + "Known problems": "None.", + "Example": "```rust\nlet mut i = 0;\nfor item in &v {\n bar(i, *item);\n i += 1;\n}\n```\nCould be written as\n```rust\nfor (i, item) in v.iter().enumerate() { bar(i, *item); }\n```" + } + }, + { + "id": "explicit_into_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `y.into_iter()` where `y` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "None", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.into_iter() {\n // ..\n}\n```\ncan be rewritten to\n```rust\nfor x in y {\n // ..\n}\n```" + } + }, + { + "id": "explicit_iter_loop", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for loops on `x.iter()` where `&x` will do, and\nsuggests the latter.", + "Why is this bad": "Readability.", + "Known problems": "False negatives. We currently only warn on some known\ntypes.", + "Example": "```rust\n// with `y` a `Vec` or slice:\nfor x in y.iter() {\n // ..\n}\n```\ncan be rewritten to\n```rust\nfor x in &y {\n // ..\n}\n```" + } + }, + { + "id": "explicit_write", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `write!()` / `writeln()!` which can be\nreplaced with `(e)print!()` / `(e)println!()`", + "Why is this bad": "Using `(e)println! is clearer and more concise", + "Known problems": "None.", + "Example": "```rust\n// this would be clearer as `eprintln!(\"foo: {:?}\", bar);`\nwriteln!(&mut std::io::stderr(), \"foo: {:?}\", bar).unwrap();\n```" + } + }, + { + "id": "extend_from_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::extend`, which was slower than\n`Vec::extend_from_slice`. Thanks to specialization, this is no longer true." + } + }, + { + "id": "extra_unused_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetimes in generics that are never used\nanywhere else.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "None.", + "Example": "```rust\n// Bad: unnecessary lifetimes\nfn unused_lifetime<'a>(x: u8) {\n // ..\n}\n\n// Good\nfn no_lifetime(x: u8) {\n // ...\n}\n```" + } + }, + { + "id": "fallible_impl_from", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for impls of `From<..>` that contain `panic!()` or `unwrap()`", + "Why is this bad": "`TryFrom` should be used if there's a possibility of failure.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo(i32);\nimpl From for Foo {\n fn from(s: String) -> Self {\n Foo(s.parse().unwrap())\n }\n}\n```" + } + }, + { + "id": "filter_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter(_).map(_)`,\n`_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\nlet vec = vec![1];\nvec.iter().filter(|x| **x == 0).map(|x| *x * 2);\n```" + } + }, + { + "id": "filter_map_next", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.filter_map(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "filter_next", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.filter(_).next()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.find(_)`.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().filter(|x| **x == 0).next();\n```\nCould be written as\n```rust\nvec.iter().find(|x| **x == 0);\n```" + } + }, + { + "id": "find_map", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.find(_).map(_)`.", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "Often requires a condition + Option/Iterator creation\ninside the closure.", + "Example": "```rust\n (0..3).find(|x| *x == 2).map(|x| x * 2);\n```\nCan be written as\n```rust\n (0..3).find_map(|x| if x == 2 { Some(x * 2) } else { None });\n```" + } + }, + { + "id": "flat_map_identity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `flat_map(|x| x)`.", + "Why is this bad": "Readability, this can be written more concisely by using `flatten`.", + "Known problems": "None", + "Example": "```rust\niter.flat_map(|x| x);\n```\nCan be written as\n```rust\niter.flatten();\n```" + } + }, + { + "id": "float_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for float arithmetic.", + "Why is this bad": "For some embedded systems or kernel development, it\ncan be useful to rule out floating-point numbers.", + "Known problems": "None.", + "Example": "```rust\na + 1.0;\n```" + } + }, + { + "id": "float_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalues (apart from zero), except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nlet x = 1.2331f64;\nlet y = 1.2332f64;\nif y == 1.23f64 { }\nif y != x {} // where both are floats\n```" + } + }, + { + "id": "float_cmp_const", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for (in-)equality comparisons on floating-point\nvalue and constant, except in functions called `*eq*` (which probably\nimplement equality for a type involving floats).", + "Why is this bad": "Floating point calculations are usually imprecise, so\nasking if two values are *exactly* equal is asking for trouble. For a good\nguide on what to do, see [the floating point\nguide](http://www.floating-point-gui.de/errors/comparison).", + "Known problems": "None.", + "Example": "```rust\nlet x: f64 = 1.0;\nconst ONE: f64 = 1.00;\nx == ONE; // where both are floats\n```" + } + }, + { + "id": "fn_to_numeric_cast", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of function pointers to something other than usize", + "Why is this bad": "Casting a function pointer to anything other than usize/isize is not portable across\narchitectures, because you end up losing bits if the target type is too small or end up with a\nbunch of extra bits that waste space and add more instructions to the final binary than\nstrictly necessary for the problem\n\nCasting to isize also doesn't make sense since there are no signed addresses.", + "Example": "```rust\n// Bad\nfn fun() -> i32 { 1 }\nlet a = fun as i64;\n\n// Good\nfn fun2() -> i32 { 1 }\nlet a = fun2 as usize;\n```" + } + }, + { + "id": "fn_to_numeric_cast_with_truncation", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for casts of a function pointer to a numeric type not wide enough to\nstore address.", + "Why is this bad": "Such a cast discards some bits of the function's address. If this is intended, it would be more\nclearly expressed by casting to usize first, then casting the usize to the intended type (with\na comment) to perform the truncation.", + "Example": "```rust\n// Bad\nfn fn1() -> i16 {\n 1\n};\nlet _ = fn1 as i32;\n\n// Better: Cast to usize first, then comment with the reason for the truncation\nfn fn2() -> i16 {\n 1\n};\nlet fn_ptr = fn2 as usize;\nlet fn_ptr_truncated = fn_ptr as i32;\n```" + } + }, + { + "id": "for_kv_map", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for iterating a map (`HashMap` or `BTreeMap`) and\nignoring either the keys or values.", + "Why is this bad": "Readability. There are `keys` and `values` methods that\ncan be used to express that don't need the values or keys.", + "Known problems": "None.", + "Example": "```ignore\nfor (k, _) in &map {\n ..\n}\n```\n\ncould be replaced by\n\n```ignore\nfor k in map.keys() {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_option", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Option` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in option {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Some(x) = option {\n ..\n}\n```" + } + }, + { + "id": "for_loop_over_result", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `for` loops over `Result` values.", + "Why is this bad": "Readability. This is more clearly expressed as an `if\nlet`.", + "Known problems": "None.", + "Example": "```ignore\nfor x in result {\n ..\n}\n```\n\nThis should be\n```ignore\nif let Ok(x) = result {\n ..\n}\n```" + } + }, + { + "id": "forget_copy", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a value that\nderives the Copy trait", + "Why is this bad": "Calling `std::mem::forget` [does nothing for types that\nimplement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the\nvalue will be copied and moved into the function on invocation.\n\nAn alternative, but also valid, explanation is that Copy types do not\nimplement\nthe Drop trait, which means they have no destructors. Without a destructor,\nthere\nis nothing for `std::mem::forget` to ignore.", + "Known problems": "None.", + "Example": "```rust\nlet x: i32 = 42; // i32 implements Copy\nstd::mem::forget(x) // A copy of x is passed to the function, leaving the\n // original unaffected\n```" + } + }, + { + "id": "forget_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls to `std::mem::forget` with a reference\ninstead of an owned value.", + "Why is this bad": "Calling `forget` on a reference will only forget the\nreference itself, which is a no-op. It will not forget the underlying\nreferenced\nvalue, which is likely what was intended.", + "Known problems": "None.", + "Example": "```rust\nlet x = Box::new(1);\nstd::mem::forget(&x) // Should have been forget(x), x will still be dropped\n```" + } + }, + { + "id": "get_last_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for using `x.get(x.len() - 1)` instead of\n`x.last()`.", + "Why is this bad": "Using `x.last()` is easier to read and has the same\nresult.\n\nNote that using `x[x.len() - 1]` is semantically different from\n`x.last()`. Indexing into the array will panic on out-of-bounds\naccesses, while `x.get()` and `x.last()` will return `None`.\n\nThere is another lint (get_unwrap) that covers the case of using\n`x.get(index).unwrap()` instead of `x[index]`.", + "Known problems": "None.", + "Example": "```rust\n// Bad\nlet x = vec![2, 3, 5];\nlet last_element = x.get(x.len() - 1);\n\n// Good\nlet x = vec![2, 3, 5];\nlet last_element = x.last();\n```" + } + }, + { + "id": "get_unwrap", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `.get().unwrap()` (or\n`.get_mut().unwrap`) on a standard library type which implements `Index`", + "Why is this bad": "Using the Index trait (`[]`) is more clear and more\nconcise.", + "Known problems": "Not a replacement for error handling: Using either\n`.unwrap()` or the Index trait (`[]`) carries the risk of causing a `panic`\nif the value being accessed is `None`. If the use of `.get().unwrap()` is a\ntemporary placeholder for dealing with the `Option` type, then this does\nnot mitigate the need for error handling. If there is a chance that `.get()`\nwill be `None` in your program, then it is advisable that the `None` case\nis handled in a future refactor instead of using `.unwrap()` or the Index\ntrait.", + "Example": "```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec.get(3).unwrap();\n*some_vec.get_mut(0).unwrap() = 1;\n```\nThe correct use would be:\n```rust\nlet mut some_vec = vec![0, 1, 2, 3];\nlet last = some_vec[3];\nsome_vec[0] = 1;\n```" + } + }, + { + "id": "identity_conversion", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for always-identical `Into`/`From`/`IntoIter` conversions.", + "Why is this bad": "Redundant code.", + "Known problems": "None.", + "Example": "```rust\n// format!() returns a `String`\nlet s: String = format!(\"hello\").into();\n```" + } + }, + { + "id": "identity_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for identity operations, e.g., `x + 0`.", + "Why is this bad": "This code can be removed without changing the\nmeaning. So it just obscures what's going on. Delete it mercilessly.", + "Known problems": "None.", + "Example": "```rust\nx / 1 + 0 * 1 - 0 | 0;\n```" + } + }, + { + "id": "if_let_redundant_pattern_matching", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "The original rule will only lint for `if let`. After\nmaking it support to lint `match`, naming as `if let` is not suitable for it.\nSo, this lint is deprecated." + } + }, + { + "id": "if_let_some_result", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "* Checks for unnecessary `ok()` in if let.", + "Why is this bad": "Calling `ok()` in if let is unnecessary, instead match\non `Ok(pat)`", + "Known problems": "None.", + "Example": "```ignore\nfor result in iter {\n if let Some(bench) = try!(result).parse().ok() {\n vec.push(bench)\n }\n}\n```\nCould be written:\n\n```ignore\nfor result in iter {\n if let Ok(bench) = try!(result).parse() {\n vec.push(bench)\n }\n}\n```" + } + }, + { + "id": "if_not_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `!` or `!=` in an if condition with an\nelse branch.", + "Why is this bad": "Negations reduce the readability of statements.", + "Known problems": "None.", + "Example": "```rust\nif !v.is_empty() {\n a()\n} else {\n b()\n}\n```\n\nCould be written:\n\n```rust\nif v.is_empty() {\n b()\n} else {\n a()\n}\n```" + } + }, + { + "id": "if_same_then_else", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `if/else` with the same body as the *then* part\nand the *else* part.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nlet foo = if \u2026 {\n 42\n} else {\n 42\n};\n```" + } + }, + { + "id": "ifs_same_cond", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for consecutive `if`s with the same condition.", + "Why is this bad": "This is probably a copy & paste error.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nif a == b {\n \u2026\n} else if a == b {\n \u2026\n}\n```\n\nNote that this lint ignores all conditions with a function call as it could\nhave side effects:\n\n```ignore\nif foo() {\n \u2026\n} else if foo() { // not linted\n \u2026\n}\n```" + } + }, + { + "id": "implicit_hasher", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for public `impl` or `fn` missing generalization\nover different hashers and implicitly defaulting to the default hashing\nalgorithm (`SipHash`).", + "Why is this bad": "`HashMap` or `HashSet` with custom hashers cannot be\nused with them.", + "Known problems": "Suggestions for replacing constructors can contain\nfalse-positives. Also applying suggestions can require modification of other\npieces of code, possibly including external crates.", + "Example": "```rust\nimpl Serialize for HashMap { }\n\npub fn foo(map: &mut HashMap) { }\n```\ncould be rewritten as\n```rust\nimpl Serialize for HashMap { }\n\npub fn foo(map: &mut HashMap) { }\n```" + } + }, + { + "id": "implicit_return", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for missing return statements at the end of a block.", + "Why is this bad": "Actually omitting the return keyword is idiomatic Rust code. Programmers\ncoming from other languages might prefer the expressiveness of `return`. It's possible to miss\nthe last returning statement because the only difference is a missing `;`. Especially in bigger\ncode with multiple return paths having a `return` keyword makes it easier to find the\ncorresponding statements.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: usize) -> usize {\n x\n}\n```\nadd return\n```rust\nfn foo(x: usize) -> usize {\n return x;\n}\n```" + } + }, + { + "id": "inconsistent_digit_grouping", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral or floating-point constant is\ngrouped inconsistently with underscores.", + "Why is this bad": "Readers may incorrectly interpret inconsistently\ngrouped digits.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 618_64_9189_73_511;\n```" + } + }, + { + "id": "indexing_slicing", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks 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.", + "Why is this bad": "Indexing and slicing can panic at runtime and there are\nsafe alternatives.", + "Known problems": "Hopefully none.", + "Example": "```rust,no_run\n// Vector\nlet x = vec![0; 5];\n\n// Bad\nx[2];\n&x[2..100];\n&x[2..];\n&x[..100];\n\n// Good\nx.get(2);\nx.get(2..100);\nx.get(2..);\nx.get(..100);\n\n// Array\nlet y = [0, 1, 2, 3];\n\n// Bad\n&y[10..100];\n&y[10..];\n&y[..100];\n\n// Good\n&y[2..];\n&y[..2];\n&y[0..3];\ny.get(10);\ny.get(10..100);\ny.get(10..);\ny.get(..100);\n```" + } + }, + { + "id": "ineffective_bit_mask", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for bit masks in comparisons which can be removed\nwithout changing the outcome. The basic structure can be seen in the\nfollowing table:\n\n|Comparison| Bit Op |Example |equals |\n|----------|---------|-----------|-------|\n|`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|\n|`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|", + "Why is this bad": "Not equally evil as [`bad_bit_mask`](#bad_bit_mask),\nbut still a bit misleading, because the bit mask is ineffective.", + "Known problems": "False negatives: This lint will only match instances\nwhere we have figured out the math (which is for a power-of-two compared\nvalue). This means things like `x | 1 >= 7` (which would be better written\nas `x >= 6`) will not be reported (but bit masks like this are fairly\nuncommon).", + "Example": "```rust\nif (x | 1 > 3) { }\n```" + } + }, + { + "id": "inefficient_to_string", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.to_string()` on an `&&T` where\n`T` implements `ToString` directly (like `&&str` or `&&String`).", + "Why is this bad": "This bypasses the specialized implementation of\n`ToString` and instead goes through the more expensive string formatting\nfacilities.", + "Known problems": "None.", + "Example": "```rust\n// Generic implementation for `T: Display` is used (slow)\n[\"foo\", \"bar\"].iter().map(|s| s.to_string());\n\n// OK, the specialized impl is used\n[\"foo\", \"bar\"].iter().map(|&s| s.to_string());\n```" + } + }, + { + "id": "infallible_destructuring_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches being used to destructure a single-variant enum\nor tuple struct where a `let` will suffice.", + "Why is this bad": "Just readability \u2013 `let` doesn't nest, whereas a `match` does.", + "Known problems": "None.", + "Example": "```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\n\nlet data = match wrapper {\n Wrapper::Data(i) => i,\n};\n```\n\nThe correct use would be:\n```rust\nenum Wrapper {\n Data(i32),\n}\n\nlet wrapper = Wrapper::Data(42);\nlet Wrapper::Data(data) = wrapper;\n```" + } + }, + { + "id": "infinite_iter", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for iteration that is guaranteed to be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "None.", + "Example": "```no_run\nuse std::iter;\n\niter::repeat(1_u8).collect::>();\n```" + } + }, + { + "id": "inherent_to_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the definition of inherent methods with a signature of `to_string(&self) -> String`.", + "Why is this bad": "This method is also implicitly defined if a type implements the `Display` trait. As the functionality of `Display` is much more versatile, it should be preferred.", + "Known problems": "None", + " Example": "```rust\n// Bad\npub struct A;\n\nimpl A {\n pub fn to_string(&self) -> String {\n \"I am A\".to_string()\n }\n}\n```\n\n```rust\n// Good\nuse std::fmt;\n\npub struct A;\n\nimpl fmt::Display for A {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n write!(f, \"I am A\")\n }\n}\n```" + } + }, + { + "id": "inherent_to_string_shadow_display", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the definition of inherent methods with a signature of `to_string(&self) -> String` and if the type implementing this method also implements the `Display` trait.", + "Why is this bad": "This method is also implicitly defined if a type implements the `Display` trait. The less versatile inherent method will then shadow the implementation introduced by `Display`.", + "Known problems": "None", + " Example": "```rust\n// Bad\nuse std::fmt;\n\npub struct A;\n\nimpl A {\n pub fn to_string(&self) -> String {\n \"I am A\".to_string()\n }\n}\n\nimpl fmt::Display for A {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n write!(f, \"I am A, too\")\n }\n}\n```\n\n```rust\n// Good\nuse std::fmt;\n\npub struct A;\n\nimpl fmt::Display for A {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n write!(f, \"I am A\")\n }\n}\n```" + } + }, + { + "id": "inline_always", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items annotated with `#[inline(always)]`,\nunless the annotated function is empty or simply panics.", + "Why is this bad": "While there are valid uses of this annotation (and once\nyou know when to use it, by all means `allow` this lint), it's a common\nnewbie-mistake to pepper one's code with it.\n\nAs a rule of thumb, before slapping `#[inline(always)]` on a function,\nmeasure if that additional function call really affects your runtime profile\nsufficiently to make up for the increase in compile time.", + "Known problems": "False positives, big time. This lint is meant to be\ndeactivated by everyone doing serious performance work. This means having\ndone the measurement.", + "Example": "```ignore\n#[inline(always)]\nfn not_quite_hot_code(..) { ... }\n```" + } + }, + { + "id": "inline_fn_without_body", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `#[inline]` on trait methods without bodies", + "Why is this bad": "Only implementations of trait methods may be inlined.\nThe inline attribute is ignored for trait methods without bodies.", + "Known problems": "None.", + "Example": "```rust\ntrait Animal {\n #[inline]\n fn name(&self) -> &'static str;\n}\n```" + } + }, + { + "id": "int_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `x >= y + 1` or `x - 1 >= y` (and `<=`) in a block", + "Why is this bad": "Readability -- better to use `> y` instead of `>= y + 1`.", + "Known problems": "None.", + "Example": "```rust\nif x >= y + 1 {}\n```\n\nCould be written as:\n\n```rust\nif x > y {}\n```" + } + }, + { + "id": "integer_arithmetic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for plain integer arithmetic.", + "Why is this bad": "This is only checked against overflow in debug builds.\nIn some applications one wants explicitly checked, wrapping or saturating\narithmetic.", + "Known problems": "None.", + "Example": "```rust\na + 1;\n```" + } + }, + { + "id": "integer_division", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for division of integers", + "Why is this bad": "When outside of some very specific algorithms,\ninteger division is very often a mistake because it discards the\nremainder.", + "Known problems": "None.", + "Example": "```rust\nfn main() {\n let x = 3 / 2;\n println!(\"{}\", x);\n}\n```" + } + }, + { + "id": "into_iter_on_array", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint has been uplifted to rustc and is now called\n`array_into_iter`." + } + }, + { + "id": "into_iter_on_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `into_iter` calls on references which should be replaced by `iter`\nor `iter_mut`.", + "Why is this bad": "Readability. Calling `into_iter` on a reference will not move out its\ncontent into the resulting iterator, which is confusing. It is better just call `iter` or\n`iter_mut` directly.", + "Known problems": "None", + "Example": "```rust\nlet _ = (&vec![3, 4, 5]).into_iter();\n```" + } + }, + { + "id": "invalid_ref", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint has been superseded by the warn-by-default\n`invalid_value` rustc lint." + } + }, + { + "id": "invalid_regex", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks [regex](https://crates.io/crates/regex) creation\n(with `Regex::new`,`RegexBuilder::new` or `RegexSet::new`) for correct\nregex syntax.", + "Why is this bad": "This will lead to a runtime panic.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"|\")\n```" + } + }, + { + "id": "invalid_upcast_comparisons", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for comparisons where the relation is always either\ntrue or false, but where one side has been upcast so that the comparison is\nnecessary. Only integer types are checked.", + "Why is this bad": "An expression like `let x : u8 = ...; (x as u32) > 300`\nwill mistakenly imply that it is possible for `x` to be outside the range of\n`u8`.", + "Known problems": "https://github.com/rust-lang/rust-clippy/issues/886", + "Example": "```rust\nlet x: u8 = 1;\n(x as u32) > 300;\n```" + } + }, + { + "id": "items_after_statements", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for items declared after some statement in a block.", + "Why is this bad": "Items live for the entire scope they are declared\nin. But statements are processed in order. This might cause confusion as\nit's hard to figure out which item is meant in a statement.", + "Known problems": "None.", + "Example": "```rust\nfn foo() {\n println!(\"cake\");\n}\n\nfn main() {\n foo(); // prints \"foo\"\n fn foo() {\n println!(\"foo\");\n }\n foo(); // prints \"foo\"\n}\n```" + } + }, + { + "id": "iter_cloned_collect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.cloned().collect()` on slice to\ncreate a `Vec`.", + "Why is this bad": "`.to_vec()` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s[..].iter().cloned().collect();\n```\nThe better use would be:\n```rust\nlet s = [1, 2, 3, 4, 5];\nlet s2: Vec = s.to_vec();\n```" + } + }, + { + "id": "iter_next_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops on `x.next()`.", + "Why is this bad": "`next()` returns either `Some(value)` if there was a\nvalue, or `None` otherwise. The insidious thing is that `Option<_>`\nimplements `IntoIterator`, so that possibly one value will be iterated,\nleading to some hard to find bugs. No one will want to write such code\n[except to win an Underhanded Rust\nContest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).", + "Known problems": "None.", + "Example": "```ignore\nfor x in y.next() {\n ..\n}\n```" + } + }, + { + "id": "iter_nth", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.iter().nth()` (and the related\n`.iter_mut().nth()`) on standard library types with O(1) element access.", + "Why is this bad": "`.get()` and `.get_mut()` are more efficient and more\nreadable.", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.get(3);\nlet bad_slice = &some_vec[..].get(3);\n```" + } + }, + { + "id": "iter_skip_next", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `.skip(x).next()` on iterators.", + "Why is this bad": "`.nth(x)` is cleaner", + "Known problems": "None.", + "Example": "```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().skip(3).next();\nlet bad_slice = &some_vec[..].iter().skip(3).next();\n```\nThe correct use would be:\n```rust\nlet some_vec = vec![0, 1, 2, 3];\nlet bad_vec = some_vec.iter().nth(3);\nlet bad_slice = &some_vec[..].iter().nth(3);\n```" + } + }, + { + "id": "iterator_step_by_zero", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calling `.step_by(0)` on iterators,\nwhich never terminates.", + "Why is this bad": "This very much looks like an oversight, since with\n`loop { .. }` there is an obvious better way to endlessly loop.", + "Known problems": "None.", + "Example": "```ignore\nfor x in (5..5).step_by(0) {\n ..\n}\n```" + } + }, + { + "id": "just_underscores_and_digits", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks if you have variables whose name consists of just\nunderscores and digits.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```rust\nlet _1 = 1;\nlet ___1 = 1;\nlet __1___2 = 11;\n```" + } + }, + { + "id": "large_digit_groups", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if the digits of an integral or floating-point\nconstant are grouped into groups that\nare too large.", + "Why is this bad": "Negatively impacts readability.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 6186491_8973511;\n```" + } + }, + { + "id": "large_enum_variant", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for large size differences between variants on\n`enum`s.", + "Why is this bad": "Enum size is bounded by the largest variant. Having a\nlarge variant\ncan penalize the memory layout of that enum.", + "Known problems": "None.", + "Example": "```rust\nenum Test {\n A(i32),\n B([i32; 8000]),\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `enum-variant-size-threshold: u64`: The maximum size of a enum's variant to avoid box suggestion (defaults to `200 `)." + } + }, + { + "id": "large_stack_arrays", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for local arrays that may be too large.", + "Why is this bad": "Large local arrays may cause stack overflow.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = [0u32; 1_000_000];\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `array-size-threshold: u64`: The maximum allowed size for arrays on the stack (defaults to `512_000 `)." + } + }, + { + "id": "len_without_is_empty", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for items that implement `.len()` but not\n`.is_empty()`.", + "Why is this bad": "It is good custom to have both methods, because for\nsome data structures, asking about the length will be a costly operation,\nwhereas `.is_empty()` can usually answer in constant time. Also it used to\nlead to false positives on the [`len_zero`](#len_zero) lint \u2013 currently that\nlint will ignore such entities.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n pub fn len(&self) -> usize {\n ..\n }\n}\n```" + } + }, + { + "id": "len_zero", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for getting the length of something via `.len()`\njust to compare to zero, and suggests using `.is_empty()` where applicable.", + "Why is this bad": "Some structures can answer `.is_empty()` much faster\nthan calculating their length. Notably, for slices, getting the length\nrequires a subtraction whereas `.is_empty()` is just a comparison. So it is\ngood to get into the habit of using `.is_empty()`, and having it is cheap.\nBesides, it makes the intent clearer than a manual comparison.", + "Known problems": "None.", + "Example": "```ignore\nif x.len() == 0 {\n ..\n}\nif y.len() != 0 {\n ..\n}\n```\ninstead use\n```ignore\nif x.is_empty() {\n ..\n}\nif !y.is_empty() {\n ..\n}\n```" + } + }, + { + "id": "let_and_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `let`-bindings, which are subsequently\nreturned.", + "Why is this bad": "It is just extraneous code. Remove it to make your code\nmore rusty.", + "Known problems": "None.", + "Example": "```rust\nfn foo() -> String {\n let x = String::new();\n x\n}\n```\ninstead, use\n```\nfn foo() -> String {\n String::new()\n}\n```" + } + }, + { + "id": "let_unit_value", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for binding a unit value.", + "Why is this bad": "A unit value cannot usefully be used anywhere. So\nbinding one is kind of pointless.", + "Known problems": "None.", + "Example": "```rust\nlet x = {\n 1;\n};\n```" + } + }, + { + "id": "linkedlist", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of any `LinkedList`, suggesting to use a\n`Vec` or a `VecDeque` (formerly called `RingBuf`).", + "Why is this bad": "Gankro 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`.", + "Known problems": "False positives \u2013 the instances where using a\n`LinkedList` makes sense are few and far between, but they can still happen.", + "Example": "```rust\nlet x: LinkedList = LinkedList::new();\n```" + } + }, + { + "id": "logic_bug", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for boolean expressions that contain terminals that\ncan be eliminated.", + "Why is this bad": "This is most likely a logic bug.", + "Known problems": "Ignores short circuiting behavior.", + "Example": "```ignore\nif a && b || a { ... }\n```\nThe `b` is unnecessary, the expression is equivalent to `if a`." + } + }, + { + "id": "main_recursion", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for recursion using the entrypoint.", + "Why is this bad": "Apart from special setups (which we could detect following attributes like #![no_std]),\nrecursing into main() seems like an unintuitive antipattern we should be able to detect.", + "Known problems": "None.", + "Example": "```no_run\nfn main() {\n main();\n}\n```" + } + }, + { + "id": "manual_memcpy", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for for-loops that manually copy items between\nslices that could be optimized by having a memcpy.", + "Why is this bad": "It is not as fast as a memcpy.", + "Known problems": "None.", + "Example": "```rust\nfor i in 0..src.len() {\n dst[i + 64] = src[i];\n}\n```\nCould be written as:\n```rust\ndst[64..(src.len() + 64)].clone_from_slice(&src[..]);\n```" + } + }, + { + "id": "manual_mul_add", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for expressions of the form `a * b + c`\nor `c + a * b` where `a`, `b`, `c` are floats and suggests using\n`a.mul_add(b, c)` instead.", + "Why is this bad": "Calculating `a * b + c` may lead to slight\nnumerical inaccuracies as `a * b` is rounded before being added to\n`c`. Depending on the target architecture, `mul_add()` may be more\nperformant.", + "Known problems": "This lint can emit semantic incorrect suggestions.\nFor example, for `a * b * c + d` the suggestion `a * b.mul_add(c, d)`\nis emitted, which is equivalent to `a * (b * c + d)`. (#4735)", + "Example": "```rust\nlet foo = (a * b) + c;\n```\n\ncan be written as\n\n```rust\nlet foo = a.mul_add(b, c);\n```" + } + }, + { + "id": "manual_saturating_arithmetic", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `.checked_add/sub(x).unwrap_or(MAX/MIN)`.", + "Why is this bad": "These can be written simply with `saturating_add/sub` methods.", + "Example": "```rust\nlet add = x.checked_add(y).unwrap_or(u32::max_value());\nlet sub = x.checked_sub(y).unwrap_or(u32::min_value());\n```\n\ncan be written using dedicated methods for saturating addition/subtraction as:\n\n```rust\nlet add = x.saturating_add(y);\nlet sub = x.saturating_sub(y);\n```" + } + }, + { + "id": "manual_swap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual swapping.", + "Why is this bad": "The `std::mem::swap` function exposes the intent better\nwithout deinitializing or copying either variable.", + "Known problems": "None.", + "Example": "```rust\nlet mut a = 42;\nlet mut b = 1337;\n\nlet t = b;\nb = a;\na = t;\n```\nUse std::mem::swap():\n```rust\nlet mut a = 1;\nlet mut b = 2;\nstd::mem::swap(&mut a, &mut b);\n```" + } + }, + { + "id": "many_single_char_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for too many variables whose name consists of a\nsingle character.", + "Why is this bad": "It's hard to memorize what a variable means without a\ndescriptive name.", + "Known problems": "None?", + "Example": "```ignore\nlet (a, b, c, d, e, f, g) = (...);\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `single-char-binding-names-threshold: u64`: The maximum number of single char bindings a scope may have (defaults to `5 `)." + } + }, + { + "id": "map_clone", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `iterator.map(|x| x.clone())` and suggests\n`iterator.cloned()` instead", + "Why is this bad": "Readability, this can be written more concisely", + "Known problems": "None", + "Example": "```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```" + } + }, + { + "id": "map_entry", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for uses of `contains_key` + `insert` on `HashMap`\nor `BTreeMap`.", + "Why is this bad": "Using `entry` is more efficient.", + "Known problems": "Some false negatives, eg.:\n```rust\nif !map.contains_key(&k) {\n map.insert(k.clone(), v);\n}\n```", + "Example": "```rust\nif !map.contains_key(&k) {\n map.insert(k, v);\n}\n```\ncan both be rewritten as:\n```rust\nmap.entry(k).or_insert(v);\n```" + } + }, + { + "id": "map_flatten", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).flatten(_)`,", + "Why is this bad": "Readability, this can be written more concisely as a\nsingle method call.", + "Known problems": "", + "Example": "```rust\nlet vec = vec![vec![1]];\nvec.iter().map(|x| x.iter()).flatten();\n```" + } + }, + { + "id": "match_as_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for match which is used to add a reference to an\n`Option` value.", + "Why is this bad": "Using `as_ref()` or `as_mut()` instead is shorter.", + "Known problems": "None.", + "Example": "```rust\nlet x: Option<()> = None;\nlet r: Option<&()> = match x {\n None => None,\n Some(ref v) => Some(v),\n};\n```" + } + }, + { + "id": "match_bool", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where match expression is a `bool`. It\nsuggests to replace the expression with an `if...else` block.", + "Why is this bad": "It makes the code less readable.", + "Known problems": "None.", + "Example": "```rust\nlet condition: bool = true;\nmatch condition {\n true => foo(),\n false => bar(),\n}\n```\nUse if/else instead:\n```rust\nlet condition: bool = true;\nif condition {\n foo();\n} else {\n bar();\n}\n```" + } + }, + { + "id": "match_overlapping_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for overlapping match arms.", + "Why is this bad": "It is likely to be an error and if not, makes the code\nless obvious.", + "Known problems": "None.", + "Example": "```rust\nlet x = 5;\nmatch x {\n 1...10 => println!(\"1 ... 10\"),\n 5...15 => println!(\"5 ... 15\"),\n _ => (),\n}\n```" + } + }, + { + "id": "match_ref_pats", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches where all arms match a reference,\nsuggesting to remove the reference and deref the matched expression\ninstead. It also checks for `if let &foo = bar` blocks.", + "Why is this bad": "It just makes the code less readable. That reference\ndestructuring adds nothing to the code.", + "Known problems": "None.", + "Example": "```rust,ignore\nmatch x {\n &A(ref y) => foo(y),\n &B => bar(),\n _ => frob(&x),\n}\n```" + } + }, + { + "id": "match_same_arms", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for `match` with identical arm bodies.", + "Why is this bad": "This is probably a copy & paste error. If arm bodies\nare the same on purpose, you can factor them\n[using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).", + "Known problems": "False positive possible with order dependent `match`\n(see issue\n[#860](https://github.com/rust-lang/rust-clippy/issues/860)).", + "Example": "```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => bar(), // <= oops\n}\n```\n\nThis should probably be\n```rust,ignore\nmatch foo {\n Bar => bar(),\n Quz => quz(),\n Baz => baz(), // <= fixed\n}\n```\n\nor if the original code was not a typo:\n```rust,ignore\nmatch foo {\n Bar | Baz => bar(), // <= shows the intent better\n Quz => quz(),\n}\n```" + } + }, + { + "id": "match_wild_err_arm", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arm which matches all errors with `Err(_)`\nand take drastic actions like `panic!`.", + "Why is this bad": "It is generally a bad practice, just like\ncatching all exceptions in java with `catch(Exception)`", + "Known problems": "None.", + "Example": "```rust\nlet x: Result = Ok(3);\nmatch x {\n Ok(_) => println!(\"ok\"),\n Err(_) => panic!(\"err\"),\n}\n```" + } + }, + { + "id": "maybe_infinite_iter", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for iteration that may be infinite.", + "Why is this bad": "While there may be places where this is acceptable\n(e.g., in event streams), in most cases this is simply an error.", + "Known problems": "The code may have a condition to stop iteration, but\nthis lint is not clever enough to analyze it.", + "Example": "```rust\nlet infinite_iter = 0..;\n[0..].iter().zip(infinite_iter.take_while(|x| *x > 5));\n```" + } + }, + { + "id": "mem_discriminant_non_enum", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `mem::discriminant()` on a non-enum type.", + "Why is this bad": "The value of `mem::discriminant()` on non-enum types\nis unspecified.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nmem::discriminant(&\"hello\");\nmem::discriminant(&&Some(2));\n```" + } + }, + { + "id": "mem_forget", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `std::mem::forget(t)` where `t` is\n`Drop`.", + "Why is this bad": "`std::mem::forget(t)` prevents `t` from running its\ndestructor, possibly causing leaks.", + "Known problems": "None.", + "Example": "```rust\nmem::forget(Rc::new(55))\n```" + } + }, + { + "id": "mem_replace_option_with_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `mem::replace()` on an `Option` with\n`None`.", + "Why is this bad": "`Option` already has the method `take()` for\ntaking its current value (Some(..) or None) and replacing it with\n`None`.", + "Known problems": "None.", + "Example": "```rust\nuse std::mem;\n\nlet mut an_option = Some(0);\nlet replaced = mem::replace(&mut an_option, None);\n```\nIs better expressed with:\n```rust\nlet mut an_option = Some(0);\nlet taken = an_option.take();\n```" + } + }, + { + "id": "mem_replace_with_uninit", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `mem::replace(&mut _, mem::uninitialized())`\nand `mem::replace(&mut _, mem::zeroed())`.", + "Why is this bad": "This will lead to undefined behavior even if the\nvalue is overwritten later, because the uninitialized value may be\nobserved in the case of a panic.", + "Known problems": "None.", + "Example": "```\nuse std::mem;\n# fn may_panic(v: Vec) -> Vec { v }\n\n#[allow(deprecated, invalid_value)]\nfn myfunc (v: &mut Vec) {\n let taken_v = unsafe { mem::replace(v, mem::uninitialized()) };\n let new_v = may_panic(taken_v); // undefined behavior on panic\n mem::forget(mem::replace(v, new_v));\n}\n```\n\nThe [take_mut](https://docs.rs/take_mut) crate offers a sound solution,\nat the cost of either lazily creating a replacement value or aborting\non panic, to ensure that the uninitialized value cannot be observed." + } + }, + { + "id": "min_max", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for expressions where `std::cmp::min` and `max` are\nused to clamp values, but switched so that the result is constant.", + "Why is this bad": "This is in all probability not the intended outcome. At\nthe least it hurts readability of the code.", + "Known problems": "None", + "Example": "```ignore\nmin(0, max(100, x))\n```\nIt will always be equal to `0`. Probably the author meant to clamp the value\nbetween 0 and 100, but has erroneously swapped `min` and `max`." + } + }, + { + "id": "misaligned_transmute", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint should never have applied to non-pointer types, as transmuting\nbetween non-pointer types of differing alignment is well-defined behavior (it's semantically\nequivalent to a memcpy). This lint has thus been refactored into two separate lints:\ncast_ptr_alignment and transmute_ptr_to_ptr." + } + }, + { + "id": "misrefactored_assign_op", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `a op= a op b` or `a op= b op a` patterns.", + "Why is this bad": "Most likely these are bugs where one meant to write `a\nop= b`.", + "Known problems": "Clippy cannot know for sure if `a op= a op b` should have\nbeen `a = a op a op b` or `a = a op b`/`a op= b`. Therefore, it suggests both.\nIf `a op= a op b` is really the correct behaviour it should be\nwritten as `a = a op a op b` as it's less confusing.", + "Example": "```rust\nlet mut a = 5;\nlet b = 2;\n// ...\na += a + b;\n```" + } + }, + { + "id": "missing_const_for_fn", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Suggests the use of `const` in functions and methods where possible.", + "Why is this bad": "Not having the function const prevents callers of the function from being const as well.", + "Known problems": "Const 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.", + "Example": "```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```" + } + }, + { + "id": "missing_docs_in_private_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Warns if there is missing doc for any documentable item\n(public or private).", + "Why is this bad": "Doc 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.", + "Known problems": "None." + } + }, + { + "id": "missing_errors_doc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks the doc comments of publicly visible functions that\nreturn a `Result` type and warns if there is no `# Errors` section.", + "Why is this bad": "Documenting the type of errors that can be returned from a\nfunction can help callers write code to handle the errors appropriately.", + "Known problems": "None.", + "Examples": "Since the following function returns a `Result` it has an `# Errors` section in\nits doc comment:\n\n```rust\n/// # Errors\n///\n/// Will return `Err` if `filename` does not exist or the user does not have\n/// permission to read it.\npub fn read(filename: String) -> io::Result {\n unimplemented!();\n}\n```" + } + }, + { + "id": "missing_inline_in_public_items", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "it lints if an exported function, method, trait method with default impl,\nor trait method impl is not `#[inline]`.", + "Why is this bad": "In general, it is not. Functions can be inlined across\ncrates when that's profitable as long as any form of LTO is used. When LTO is disabled,\nfunctions that are not `#[inline]` cannot be inlined across crates. Certain types of crates\nmight intend for most of the methods in their public API to be able to be inlined across\ncrates even when LTO is disabled. For these types of crates, enabling this lint might make\nsense. It allows the crate to require all exported methods to be `#[inline]` by default, and\nthen opt out for specific methods where this might not make sense.", + "Known problems": "None.", + "Example": "```rust\npub fn foo() {} // missing #[inline]\nfn ok() {} // ok\n#[inline] pub fn bar() {} // ok\n#[inline(always)] pub fn baz() {} // ok\n\npub trait Bar {\n fn bar(); // ok\n fn def_bar() {} // missing #[inline]\n}\n\nstruct Baz;\nimpl Baz {\n fn private() {} // ok\n}\n\nimpl Bar for Baz {\n fn bar() {} // ok - Baz is not exported\n}\n\npub struct PubBaz;\nimpl PubBaz {\n fn private() {} // ok\n pub fn not_ptrivate() {} // missing #[inline]\n}\n\nimpl Bar for PubBaz {\n fn bar() {} // missing #[inline]\n fn def_bar() {} // missing #[inline]\n}\n```" + } + }, + { + "id": "missing_safety_doc", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the doc comments of publicly visible\nunsafe functions and warns if there is no `# Safety` section.", + "Why is this bad": "Unsafe functions should document their safety\npreconditions, so that users can be sure they are using them safely.", + "Known problems": "None.", + "Examples": "```rust\n/// This function should really be documented\npub unsafe fn start_apocalypse(u: &mut Universe) {\n unimplemented!();\n}\n```\n\nAt least write a line about safety:\n\n```rust\n/// # Safety\n///\n/// This function should not be called before the horsemen are ready.\npub unsafe fn start_apocalypse(u: &mut Universe) {\n unimplemented!();\n}\n```" + } + }, + { + "id": "mistyped_literal_suffixes", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Warns for mistyped suffix in literals", + "Why is this bad": "This is most probably a typo", + "Known problems": "- Recommends a signed suffix, even though the number might be too big and an unsigned\n suffix is required\n- Does not match on `_128` since that is a valid grouping for decimal and octal numbers", + "Example": "```rust\n2_32;\n```" + } + }, + { + "id": "mixed_case_hex_literals", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns on hexadecimal literals with mixed-case letter\ndigits.", + "Why is this bad": "It looks confusing.", + "Known problems": "None.", + "Example": "```rust\nlet y = 0x1a9BAcD;\n```" + } + }, + { + "id": "module_inception", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for modules that have the same name as their\nparent module", + "Why is this bad": "A 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.", + "Known problems": "None.", + "Example": "```ignore\n// lib.rs\nmod foo;\n// foo.rs\nmod foo {\n ...\n}\n```" + } + }, + { + "id": "module_name_repetitions", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects type names that are prefixed or suffixed by the\ncontaining module's name.", + "Why is this bad": "It requires the user to type the module name twice.", + "Known problems": "None.", + "Example": "```rust\nmod cake {\n struct BlackForestCake;\n}\n```" + } + }, + { + "id": "modulo_one", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the remainder of a division by one.", + "Why is this bad": "The result can only ever be zero. No one will write\nsuch code deliberately, unless trying to win an Underhanded Rust\nContest. Even for that contest, it's probably a bad idea. Use something more\nunderhanded.", + "Known problems": "None.", + "Example": "```rust\nlet a = x % 1;\n```" + } + }, + { + "id": "multiple_crate_versions", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks to see if multiple versions of a crate are being\nused.", + "Why is this bad": "This bloats the size of targets, and can lead to\nconfusing error messages when structs or traits are used interchangeably\nbetween different versions of a crate.", + "Known problems": "Because this can be caused purely by the dependencies\nthemselves, it's not always possible to fix this issue.", + "Example": "```toml\n# This will pull in both winapi v0.3.4 and v0.2.8, triggering a warning.\n[dependencies]\nctrlc = \"3.1.0\"\nansi_term = \"0.11.0\"\n```" + } + }, + { + "id": "multiple_inherent_impl", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for multiple inherent implementations of a struct", + "Why is this bad": "Splitting the implementation of a type makes the code harder to navigate.", + "Known problems": "None.", + "Example": "```rust\nstruct X;\nimpl X {\n fn one() {}\n}\nimpl X {\n fn other() {}\n}\n```\n\nCould be written:\n\n```rust\nstruct X;\nimpl X {\n fn one() {}\n fn other() {}\n}\n```" + } + }, + { + "id": "must_use_candidate", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for public functions that have no\n[`#[must_use]`] attribute, but return something not already marked\nmust-use, have no mutable arg and mutate no statics.\n\n[`#[must_use]`]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute", + "Why is this bad": "Not bad at all, this lint just shows places where\nyou could add the attribute.", + "Known problems": "The lint only checks the arguments for mutable\ntypes without looking if they are actually changed. On the other hand,\nit also ignores a broad range of potentially interesting side effects,\nbecause we cannot decide whether the programmer intends the function to\nbe called for the side effect or the result. Expect many false\npositives. At least we don't lint if the result type is unit or already\n`#[must_use]`.", + "Examples": "```rust\n// this could be annotated with `#[must_use]`.\nfn id(t: T) -> T { t }\n```" + } + }, + { + "id": "must_use_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for a [`#[must_use]`] attribute on\nunit-returning functions and methods.\n\n[`#[must_use]`]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute", + "Why is this bad": "Unit values are useless. The attribute is likely\na remnant of a refactoring that removed the return type.", + "Known problems": "None.", + "Examples": "```rust\n#[must_use]\nfn useless() { }\n```" + } + }, + { + "id": "mut_from_ref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "This lint checks for functions that take immutable\nreferences and return\nmutable ones.", + "Why is this bad": "This is trivially unsound, as one can create two\nmutable references\nfrom the same (immutable!) source. This\n[error](https://github.com/rust-lang/rust/issues/39465)\nactually lead to an interim Rust release 1.15.1.", + "Known problems": "To be on the conservative side, if there's at least one\nmutable reference\nwith the output lifetime, this lint will not trigger. In practice, this\ncase is unlikely anyway.", + "Example": "```ignore\nfn foo(&Foo) -> &mut Bar { .. }\n```" + } + }, + { + "id": "mut_mut", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for instances of `mut mut` references.", + "Why is this bad": "Multiple `mut`s don't add anything meaningful to the\nsource. This is either a copy'n'paste error, or it shows a fundamental\nmisunderstanding of references.", + "Known problems": "None.", + "Example": "```rust\nlet x = &mut &mut y;\n```" + } + }, + { + "id": "mut_range_bound", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for loops which have a range bound that is a mutable variable", + "Why is this bad": "One might think that modifying the mutable variable changes the loop bounds", + "Known problems": "None", + "Example": "```rust\nlet mut foo = 42;\nfor i in 0..foo {\n foo -= 1;\n println!(\"{}\", i); // prints numbers from 0 to 42, not 0 to 21\n}\n```" + } + }, + { + "id": "mutex_atomic", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Mutex` where an atomic will do.", + "Why is this bad": "Using a mutex just to make access to a plain bool or\nreference sequential is shooting flies with cannons.\n`std::sync::atomic::AtomicBool` and `std::sync::atomic::AtomicPtr` are leaner and\nfaster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(&y);\n```" + } + }, + { + "id": "mutex_integer", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for usages of `Mutex` where `X` is an integral\ntype.", + "Why is this bad": "Using a mutex just to make access to a plain integer\nsequential is\nshooting flies with cannons. `std::sync::atomic::AtomicUsize` is leaner and faster.", + "Known problems": "This lint cannot detect if the mutex is actually used\nfor waiting before a critical section.", + "Example": "```rust\nlet x = Mutex::new(0usize);\n```" + } + }, + { + "id": "naive_bytecount", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for naive byte counts", + "Why is this bad": "The [`bytecount`](https://crates.io/crates/bytecount)\ncrate has methods to count your bytes faster, especially for large slices.", + "Known problems": "If you have predominantly small slices, the\n`bytecount::count(..)` method may actually be slower. However, if you can\nensure that less than 2\u00b3\u00b2-1 matches arise, the `naive_count_32(..)` can be\nfaster in those cases.", + "Example": "```rust\n&vec.iter().filter(|x| **x == 0u8).count(); // use bytecount::count instead\n```" + } + }, + { + "id": "needless_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions of the form `if c { true } else {\nfalse }`\n(or vice versa) and suggest using the condition directly.", + "Why is this bad": "Redundant code.", + "Known problems": "Maybe false positives: Sometimes, the two branches are\npainstakingly documented (which we, of course, do not detect), so they *may*\nhave some value. Even then, the documentation can be rewritten to match the\nshorter code.", + "Example": "```rust,ignore\nif x {\n false\n} else {\n true\n}\n```\nCould be written as\n```rust,ignore\n!x\n```" + } + }, + { + "id": "needless_borrow", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for address of operations (`&`) that are going to\nbe dereferenced immediately by the compiler.", + "Why is this bad": "Suggests that the receiver of the expression borrows\nthe expression.", + "Example": "```rust\nlet x: &i32 = &&&&&&5;\n```", + "Known problems": "None." + } + }, + { + "id": "needless_borrowed_reference", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for useless borrowed references.", + "Why is this bad": "It is mostly useless and make the code look more\ncomplex than it\nactually is.", + "Known problems": "It seems that the `&ref` pattern is sometimes useful.\nFor instance in the following snippet:\n```rust,ignore\nenum Animal {\n Cat(u64),\n Dog(u64),\n}\n\nfn foo(a: &Animal, b: &Animal) {\n match (a, b) {\n (&Animal::Cat(v), k) | (k, &Animal::Cat(v)) => (), // lifetime mismatch error\n (&Animal::Dog(ref c), &Animal::Dog(_)) => ()\n }\n}\n```\nThere is a lifetime mismatch error for `k` (indeed a and b have distinct\nlifetime).\nThis can be fixed by using the `&ref` pattern.\nHowever, the code can also be fixed by much cleaner ways", + "Example": "```rust\nlet mut v = Vec::::new();\nlet _ = v.iter_mut().filter(|&ref a| a.is_empty());\n```\nThis closure takes a reference on something that has been matched as a\nreference and\nde-referenced.\nAs such, it could just be |a| a.is_empty()" + } + }, + { + "id": "needless_collect", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions collecting an iterator when collect\nis not needed.", + "Why is this bad": "`collect` causes the allocation of a new data structure,\nwhen this allocation may not be needed.", + "Known problems": "None", + "Example": "```rust\nlet len = iterator.clone().collect::>().len();\n// should be\nlet len = iterator.count();\n```" + } + }, + { + "id": "needless_continue", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "The lint checks for `if`-statements appearing in loops\nthat contain a `continue` statement in either their main blocks or their\n`else`-blocks, when omitting the `else`-block possibly with some\nrearrangement of code can make the code easier to understand.", + "Why is this bad": "Having explicit `else` blocks for `if` statements\ncontaining `continue` in their THEN branch adds unnecessary branching and\nnesting to the code. Having an else block containing just `continue` can\nalso be better written by grouping the statements following the whole `if`\nstatement within the THEN block and omitting the else block completely.", + "Known problems": "None", + "Example": "```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n } else {\n continue;\n }\n println!(\"Hello, world\");\n}\n```\n\nCould be rewritten as\n\n```rust\nwhile condition() {\n update_condition();\n if x {\n // ...\n println!(\"Hello, world\");\n }\n}\n```\n\nAs another example, the following code\n\n```rust\nloop {\n if waiting() {\n continue;\n } else {\n // Do something useful\n }\n # break;\n}\n```\nCould be rewritten as\n\n```rust\nloop {\n if waiting() {\n continue;\n }\n // Do something useful\n # break;\n}\n```" + } + }, + { + "id": "needless_doctest_main", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `fn main() { .. }` in doctests", + "Why is this bad": "The test can be shorter (and likely more readable)\nif the `fn main()` is left implicit.", + "Known problems": "None.", + "Examples": "``````rust\n/// An example of a doctest with a `main()` function\n///\n/// # Examples\n///\n/// ```\n/// fn main() {\n/// // this needs not be in an `fn`\n/// }\n/// ```\nfn needless_main() {\n unimplemented!();\n}\n``````" + } + }, + { + "id": "needless_lifetimes", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for lifetime annotations which can be removed by\nrelying on lifetime elision.", + "Why is this bad": "The additional lifetimes make the code look more\ncomplicated, while there is nothing out of the ordinary going on. Removing\nthem leads to more readable code.", + "Known problems": "Potential false negatives: we bail out if the function\nhas a `where` clause where lifetimes are mentioned.", + "Example": "```rust\n// Bad: unnecessary lifetime annotations\nfn in_and_out<'a>(x: &'a u8, y: u8) -> &'a u8 {\n x\n}\n\n// Good\nfn elided(x: &u8, y: u8) -> &u8 {\n x\n}\n```" + } + }, + { + "id": "needless_pass_by_value", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions taking arguments by value, but not\nconsuming them in its\nbody.", + "Why is this bad": "Taking arguments by reference is more flexible and can\nsometimes avoid\nunnecessary allocations.", + "Known problems": "* This lint suggests taking an argument by reference,\nhowever sometimes it is better to let users decide the argument type\n(by using `Borrow` trait, for example), depending on how the function is used.", + "Example": "```rust\nfn foo(v: Vec) {\n assert_eq!(v.len(), 42);\n}\n```\n\n```rust\n// should be\nfn foo(v: &[i32]) {\n assert_eq!(v.len(), 42);\n}\n```" + } + }, + { + "id": "needless_range_loop", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for looping over the range of `0..len` of some\ncollection just to get the values by index.", + "Why is this bad": "Just iterating the collection itself makes the intent\nmore clear and is probably faster.", + "Known problems": "None.", + "Example": "```rust\nlet vec = vec!['a', 'b', 'c'];\nfor i in 0..vec.len() {\n println!(\"{}\", vec[i]);\n}\n```\nCould be written as:\n```rust\nlet vec = vec!['a', 'b', 'c'];\nfor i in vec {\n println!(\"{}\", i);\n}\n```" + } + }, + { + "id": "needless_return", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for return statements at the end of a block.", + "Why is this bad": "Removing the `return` and semicolon will make the code\nmore rusty.", + "Known problems": "If the computation returning the value borrows a local\nvariable, removing the `return` may run afoul of the borrow checker.", + "Example": "```rust\nfn foo(x: usize) -> usize {\n return x;\n}\n```\nsimplify to\n```rust\nfn foo(x: usize) -> usize {\n x\n}\n```" + } + }, + { + "id": "needless_update", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for needlessly including a base struct on update\nwhen all fields are changed anyway.", + "Why is this bad": "This will cost resources (because the base has to be\nsomewhere), and make the code less readable.", + "Known problems": "None.", + "Example": "```rust\nPoint {\n x: 1,\n y: 1,\n ..zero_point\n};\n```" + } + }, + { + "id": "neg_cmp_op_on_partial_ord", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the usage of negated comparison operators on types which only implement\n`PartialOrd` (e.g., `f64`).", + "Why is this bad": "These operators make it easy to forget that the underlying types actually allow not only three\npotential Orderings (Less, Equal, Greater) but also a fourth one (Uncomparable). This is\nespecially easy to miss if the operator based comparison result is negated.", + "Known problems": "None.", + "Example": "```rust\nuse std::cmp::Ordering;\n\n// Bad\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = !(a <= b);\n\n// Good\nlet a = 1.0;\nlet b = std::f64::NAN;\n\nlet _not_less_or_equal = match a.partial_cmp(&b) {\n None | Some(Ordering::Greater) => true,\n _ => false,\n};\n```" + } + }, + { + "id": "neg_multiply", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for multiplication by -1 as a form of negation.", + "Why is this bad": "It's more readable to just negate.", + "Known problems": "This only catches integers (for now).", + "Example": "```ignore\nx * -1\n```" + } + }, + { + "id": "never_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops that will always `break`, `return` or\n`continue` an outer loop.", + "Why is this bad": "This loop never loops, all it does is obfuscating the\ncode.", + "Known problems": "None", + "Example": "```rust\nloop {\n ..;\n break;\n}\n```" + } + }, + { + "id": "new_ret_no_self", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `new` not returning `Self`.", + "Why is this bad": "As a convention, `new` methods are used to make a new\ninstance of a type.", + "Known problems": "None.", + "Example": "```ignore\nimpl Foo {\n fn new(..) -> NotAFoo {\n }\n}\n```" + } + }, + { + "id": "new_without_default", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for types with a `fn new() -> Self` method and no\nimplementation of\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).\n\nIt detects both the case when a manual\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\nimplementation is required and also when it can be created with\n`#[derive(Default)]`", + "Why is this bad": "The user might expect to be able to use\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the\ntype can be constructed without arguments.", + "Known problems": "Hopefully none.", + "Example": "```ignore\nstruct Foo(Bar);\n\nimpl Foo {\n fn new() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nInstead, use:\n\n```ignore\nstruct Foo(Bar);\n\nimpl Default for Foo {\n fn default() -> Self {\n Foo(Bar::new())\n }\n}\n```\n\nOr, if\n[`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)\ncan be derived by `#[derive(Default)]`:\n\n```rust\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nInstead, use:\n\n```rust\n#[derive(Default)]\nstruct Foo;\n\nimpl Foo {\n fn new() -> Self {\n Foo\n }\n}\n```\n\nYou can also have `new()` call `Default::default()`." + } + }, + { + "id": "no_effect", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for statements which have no effect.", + "Why is this bad": "Similar to dead code, these statements are actually\nexecuted. However, as they have no effect, all they do is make the code less\nreadable.", + "Known problems": "None.", + "Example": "```rust\n0;\n```" + } + }, + { + "id": "non_ascii_literal", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for non-ASCII characters in string literals.", + "Why is this bad": "Yeah, we know, the 90's called and wanted their charset\nback. Even so, there still are editors and other programs out there that\ndon't work well with Unicode. So if the code is meant to be used\ninternationally, on multiple operating systems, or has other portability\nrequirements, activating this lint could be useful.", + "Known problems": "None.", + "Example": "```rust\nlet x = String::from(\"\u20ac\");\n```\nCould be written as:\n```rust\nlet x = String::from(\"\\u{20ac}\");\n```" + } + }, + { + "id": "nonminimal_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for boolean expressions that can be written more\nconcisely.", + "Why is this bad": "Readability of boolean expressions suffers from\nunnecessary duplication.", + "Known problems": "Ignores short circuiting behavior of `||` and\n`&&`. Ignores `|`, `&` and `^`.", + "Example": "```ignore\nif a && true // should be: if a\nif !(a == b) // should be: if a != b\n```" + } + }, + { + "id": "nonsensical_open_options", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for duplicate open options as well as combinations\nthat make no sense.", + "Why is this bad": "In the best case, the code will be harder to read than\nnecessary. I don't know the worst case.", + "Known problems": "None.", + "Example": "```rust\nuse std::fs::OpenOptions;\n\nOpenOptions::new().read(true).truncate(true);\n```" + } + }, + { + "id": "not_unsafe_ptr_arg_deref", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for public functions that dereference raw pointer\narguments but are not marked unsafe.", + "Why is this bad": "The function should probably be marked `unsafe`, since\nfor an arbitrary raw pointer, there is no way of telling for sure if it is\nvalid.", + "Known problems": "* It does not check functions recursively so if the pointer is passed to a\nprivate non-`unsafe` function which does the dereferencing, the lint won't\ntrigger.\n* It only checks for arguments whose type are raw pointers, not raw pointers\ngot from an argument in some other way (`fn foo(bar: &[*const u8])` or\n`some_argument.get_raw_ptr()`).", + "Example": "```rust\npub fn foo(x: *const u8) {\n println!(\"{}\", unsafe { *x });\n}\n```" + } + }, + { + "id": "ok_expect", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `ok().expect(..)`.", + "Why is this bad": "Because you usually call `expect()` on the `Result`\ndirectly to get a better error message.", + "Known problems": "The error type needs to implement `Debug`", + "Example": "```ignore\nx.ok().expect(\"why did I do this again?\")\n```" + } + }, + { + "id": "op_ref", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for arguments to `==` which have their address\ntaken to satisfy a bound\nand suggests to dereference the other argument instead", + "Why is this bad": "It is more idiomatic to dereference the other argument.", + "Known problems": "None", + "Example": "```ignore\n&x == y\n```" + } + }, + { + "id": "option_and_then_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.and_then(|x| Some(y))`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map(|x| y)`.", + "Known problems": "None", + "Example": "```rust\nlet x = Some(\"foo\");\nlet _ = x.and_then(|s| Some(s.len()));\n```\n\nThe correct use would be:\n\n```rust\nlet x = Some(\"foo\");\nlet _ = x.map(|s| s.len());\n```" + } + }, + { + "id": "option_expect_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.expect()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case. Still,\n for a lot of quick-and-dirty code, `expect` is a good choice, which is why\n this lint is `Allow` by default.", + "Known problems": "None.", + "Example": "Using expect on an `Option`:\n\n```rust\nlet opt = Some(1);\nopt.expect(\"one\");\n```\n\nBetter:\n\n```ignore\nlet opt = Some(1);\nopt?;\n# Some::<()>(())\n```" + } + }, + { + "id": "option_map_or_none", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `_.map_or(None, _)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.and_then(_)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```ignore\nopt.map_or(None, |a| a + 1)\n```" + } + }, + { + "id": "option_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `option.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Option = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)));\n```\n\nThe correct use would be:\n\n```rust\nlet x: Option = do_stuff();\nif let Some(msg) = x {\n log_err_msg(msg);\n}\n\nif let Some(msg) = x {\n log_err_msg(format_msg(msg));\n}\n```" + } + }, + { + "id": "option_map_unwrap_or", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or(_, _)`.", + "Known problems": "The order of the arguments is not in execution order", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or(0);\n```" + } + }, + { + "id": "option_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `_.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.map_or_else(_, _)`.", + "Known problems": "The order of the arguments is not in execution order.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function);\n```" + } + }, + { + "id": "option_option", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Option>` in function signatures and type\ndefinitions", + "Why is this bad": "`Option<_>` represents an optional value. `Option>`\nrepresents an optional optional value which is logically the same thing as an optional\nvalue but has an unneeded extra level of wrapping.", + "Known problems": "None.", + "Example": "```rust\nfn x() -> Option> {\n None\n}\n```" + } + }, + { + "id": "option_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Option`s.", + "Why is this bad": "Usually it is better to handle the `None` case, or to\nat 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.", + "Known problems": "None.", + "Example": "Using unwrap on an `Option`:\n\n```rust\nlet opt = Some(1);\nopt.unwrap();\n```\n\nBetter:\n\n```rust\nlet opt = Some(1);\nopt.expect(\"more helpful message\");\n```" + } + }, + { + "id": "or_fun_call", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,\netc., and suggests to use `or_else`, `unwrap_or_else`, etc., or\n`unwrap_or_default` instead.", + "Why is this bad": "The function will always be called and potentially\nallocate an object acting as the default.", + "Known problems": "If the function has side-effects, not calling it will\nchange the semantic of the program, but you shouldn't rely on that anyway.", + "Example": "```rust\nfoo.unwrap_or(String::new());\n```\nthis can instead be written:\n```rust\nfoo.unwrap_or_else(String::new);\n```\nor\n```rust\nfoo.unwrap_or_default();\n```" + } + }, + { + "id": "out_of_bounds_indexing", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for out of bounds array indexing with a constant\nindex.", + "Why is this bad": "This will always panic at runtime.", + "Known problems": "Hopefully none.", + "Example": "```no_run\n# #![allow(const_err)]\nlet x = [1, 2, 3, 4];\n\n// Bad\nx[9];\n&x[2..9];\n\n// Good\nx[0];\nx[3];\n```" + } + }, + { + "id": "overflow_check_conditional", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects classic underflow/overflow checks.", + "Why is this bad": "Most classic C underflow/overflow checks will fail in\nRust. Users can use functions like `overflowing_*` and `wrapping_*` instead.", + "Known problems": "None.", + "Example": "```rust\na + b < a;\n```" + } + }, + { + "id": "panic", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `panic!`.", + "Why is this bad": "`panic!` will stop the execution of the executable", + "Known problems": "None.", + "Example": "```no_run\npanic!(\"even with a good reason\");\n```" + } + }, + { + "id": "panic_params", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for missing parameters in `panic!`.", + "Why is this bad": "Contrary to the `format!` family of macros, there are\ntwo forms of `panic!`: if there are no parameters given, the first argument\nis not a format string and used literally. So while `format!(\"{}\")` will\nfail to compile, `panic!(\"{}\")` will not.", + "Known problems": "None.", + "Example": "```no_run\npanic!(\"This `panic!` is probably missing a parameter there: {}\");\n```" + } + }, + { + "id": "panicking_unwrap", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that will always fail.", + "Why is this bad": "If panicking is desired, an explicit `panic!()` should be used.", + "Known problems": "This lint only checks `if` conditions not assignments.\nSo something like `let x: Option<()> = None; x.unwrap();` will not be recognized.", + "Example": "```rust\nif option.is_none() {\n do_something_with(option.unwrap())\n}\n```\n\nThis code will always panic. The if condition should probably be inverted." + } + }, + { + "id": "partialeq_ne_impl", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for manual re-implementations of `PartialEq::ne`.", + "Why is this bad": "`PartialEq::ne` is required to always return the\nnegated result of `PartialEq::eq`, which is exactly what the default\nimplementation does. Therefore, there should never be any need to\nre-implement it.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo;\n\nimpl PartialEq for Foo {\n fn eq(&self, other: &Foo) -> bool { true }\n fn ne(&self, other: &Foo) -> bool { !(self == other) }\n}\n```" + } + }, + { + "id": "path_buf_push_overwrite", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "* Checks for [push](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.push)\ncalls on `PathBuf` that can cause overwrites.", + "Why is this bad": "Calling `push` with a root path at the start can overwrite the\nprevious defined path.", + "Known problems": "None.", + "Example": "```rust\nuse std::path::PathBuf;\n\nlet mut x = PathBuf::from(\"/foo\");\nx.push(\"/bar\");\nassert_eq!(x, PathBuf::from(\"/bar\"));\n```\nCould be written:\n\n```rust\nuse std::path::PathBuf;\n\nlet mut x = PathBuf::from(\"/foo\");\nx.push(\"bar\");\nassert_eq!(x, PathBuf::from(\"/foo/bar\"));\n```" + } + }, + { + "id": "possible_missing_comma", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for possible missing comma in an array. It lints if\nan array element is a binary operator expression and it lies on two lines.", + "Why is this bad": "This could lead to unexpected results.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet a = &[\n -1, -2, -3 // <= no comma here\n -4, -5, -6\n];\n```" + } + }, + { + "id": "precedence", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for operations where precedence may be unclear\nand suggests to add parentheses. Currently it catches the following:\n* mixed usage of arithmetic and bit shifting/combining operators without\nparentheses\n* a \"negative\" numeric literal (which is really a unary `-` followed by a\nnumeric literal)\n followed by a method call", + "Why is this bad": "Not everyone knows the precedence of those operators by\nheart, so expressions like these may trip others trying to reason about the\ncode.", + "Known problems": "None.", + "Example": "* `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7\n* `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1" + } + }, + { + "id": "print_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `print!`/`println!` args.", + "Why is this bad": "Using literals as `println!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `println!(\"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nprintln!(\"{}\", \"foo\");\n```\nuse the literal without formatting:\n```rust\nprintln!(\"foo\");\n```" + } + }, + { + "id": "print_stdout", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for printing on *stdout*. The purpose of this lint\nis to catch debugging remnants.", + "Why is this bad": "People often print on *stdout* while debugging an\napplication and might forget to remove those prints afterward.", + "Known problems": "Only catches `print!` and `println!` calls.", + "Example": "```rust\nprintln!(\"Hello world!\");\n```" + } + }, + { + "id": "print_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `print!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `println!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nprint!(\"Hello {}!\\n\", name);\n```\nuse println!() instead\n```rust\nprintln!(\"Hello {}!\", name);\n```" + } + }, + { + "id": "println_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `println!(\"\")` to\nprint a newline.", + "Why is this bad": "You should use `println!()`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nprintln!(\"\");\n```" + } + }, + { + "id": "ptr_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint checks for function arguments of type `&String`\nor `&Vec` unless the references are mutable. It will also suggest you\nreplace `.clone()` calls with the appropriate `.to_owned()`/`to_string()`\ncalls.", + "Why is this bad": "Requiring the argument to be of the specific size\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.", + "Known problems": "The lint does not follow data. So if you have an\nargument `x` and write `let y = x; y.clone()` the lint will not suggest\nchanging that `.clone()` to `.to_owned()`.\n\nOther functions called from this function taking a `&String` or `&Vec`\nargument may also fail to compile if you change the argument. Applying\nthis lint on them will fix the problem, but they may be in other crates.\n\nAlso there may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it you may not be aware. Carefully deprecate the\nfunction before applying the lint suggestions in this case.", + "Example": "```ignore\nfn foo(&Vec) { .. }\n```" + } + }, + { + "id": "ptr_offset_with_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of the `offset` pointer method with a `usize` casted to an\n`isize`.", + "Why is this bad": "If we\u2019re always increasing the pointer address, we can avoid the numeric\ncast by using the `add` method instead.", + "Known problems": "None", + "Example": "```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.offset(offset as isize);\n}\n```\n\nCould be written:\n\n```rust\nlet vec = vec![b'a', b'b', b'c'];\nlet ptr = vec.as_ptr();\nlet offset = 1_usize;\n\nunsafe {\n ptr.add(offset);\n}\n```" + } + }, + { + "id": "pub_enum_variant_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Detects enumeration variants that are prefixed or suffixed\nby the same characters.", + "Why is this bad": "Enumeration variant names should specify their variant,\nnot repeat the enumeration name.", + "Known problems": "None.", + "Example": "```rust\nenum Cake {\n BlackForestCake,\n HummingbirdCake,\n BattenbergCake,\n}\n```" + } + }, + { + "id": "question_mark", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for expressions that could be replaced by the question mark operator.", + "Why is this bad": "Question mark usage is more idiomatic.", + "Known problems": "None", + "Example": "```ignore\nif option.is_none() {\n return None;\n}\n```\n\nCould be written:\n\n```ignore\noption?;\n```" + } + }, + { + "id": "range_minus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for inclusive ranges where 1 is subtracted from\nthe upper bound, e.g., `x..=(y-1)`.", + "Why is this bad": "The code is more readable with an exclusive range\nlike `x..y`.", + "Known problems": "None.", + "Example": "```rust,ignore\nfor x..=(y-1) { .. }\n```\nCould be written as\n```rust,ignore\nfor x..y { .. }\n```" + } + }, + { + "id": "range_plus_one", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for exclusive ranges where 1 is added to the\nupper bound, e.g., `x..(y+1)`.", + "Why is this bad": "The code is more readable with an inclusive range\nlike `x..=y`.", + "Known problems": "Will add unnecessary pair of parentheses when the\nexpression is not wrapped in a pair but starts with a opening parenthesis\nand ends with a closing one.\nI.e., `let _ = (f()+1)..(f()+1)` results in `let _ = ((f()+1)..=f())`.", + "Example": "```rust,ignore\nfor x..(y+1) { .. }\n```\nCould be written as\n```rust,ignore\nfor x..=y { .. }\n```" + } + }, + { + "id": "range_step_by_zero", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "`Range::step_by(0)` used to be linted since it's\nan infinite iterator, which is better expressed by `iter::repeat`,\nbut the method has been removed for `Iterator::step_by` which panics\nif given a zero" + } + }, + { + "id": "range_zip_with_len", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for zipping a collection with the range of\n`0.._.len()`.", + "Why is this bad": "The code is better expressed with `.enumerate()`.", + "Known problems": "None.", + "Example": "```rust\nx.iter().zip(0..x.len());\n```\nCould be written as\n```rust\nx.iter().enumerate();\n```" + } + }, + { + "id": "redundant_clone", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for a redudant `clone()` (and its relatives) which clones an owned\nvalue that is going to be dropped without further use.", + "Why is this bad": "It is not always possible for the compiler to eliminate useless\nallocations and deallocations generated by redundant `clone()`s.", + "Known problems": "False-negatives: analysis performed by this lint is conservative and limited.", + "Example": "```rust\n{\n let x = Foo::new();\n call(x.clone());\n call(x.clone()); // this can just pass `x`\n}\n\n[\"lorem\", \"ipsum\"].join(\" \").to_string();\n\nPath::new(\"/a/b\").join(\"c\").to_path_buf();\n```" + } + }, + { + "id": "redundant_closure", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for closures which just call another function where\nthe function can be called directly. `unsafe` functions or calls where types\nget adjusted are ignored.", + "Why is this bad": "Needlessly creating a closure adds code for no benefit\nand gives the optimizer more work.", + "Known problems": "If creating the closure inside the closure has a side-\neffect then moving the closure creation out will change when that side-\neffect runs.\nSee rust-lang/rust-clippy#1439 for more details.", + "Example": "```rust,ignore\nxs.map(|x| foo(x))\n```\nwhere `foo(_)` is a plain function that takes the exact argument type of\n`x`." + } + }, + { + "id": "redundant_closure_call", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects closures called in the same expression where they\nare defined.", + "Why is this bad": "It is unnecessarily adding to the expression's\ncomplexity.", + "Known problems": "None.", + "Example": "```rust,ignore\n(|| 42)()\n```" + } + }, + { + "id": "redundant_closure_for_method_calls", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for closures which only invoke a method on the closure\nargument and can be replaced by referencing the method directly.", + "Why is this bad": "It's unnecessary to create the closure.", + "Known problems": "rust-lang/rust-clippy#3071, rust-lang/rust-clippy#4002,\nrust-lang/rust-clippy#3942", + "Example": "```rust,ignore\nSome('a').map(|s| s.to_uppercase());\n```\nmay be rewritten as\n```rust,ignore\nSome('a').map(char::to_uppercase);\n```" + } + }, + { + "id": "redundant_field_names", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for fields in struct literals where shorthands\ncould be used.", + "Why is this bad": "If the field and variable names are the same,\nthe field name is redundant.", + "Known problems": "None.", + "Example": "```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```ignore\nlet foo = Foo { bar };\n```" + } + }, + { + "id": "redundant_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for patterns in the form `name @ _`.", + "Why is this bad": "It's almost always more readable to just use direct\nbindings.", + "Known problems": "None.", + "Example": "```rust\n\nmatch v {\n Some(x) => (),\n y @ _ => (), // easier written as `y`,\n}\n```" + } + }, + { + "id": "redundant_pattern_matching", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Lint for redundant pattern matching over `Result` or\n`Option`", + "Why is this bad": "It's more concise and clear to just use the proper\nutility function", + "Known problems": "None.", + "Example": "```rust\nif let Ok(_) = Ok::(42) {}\nif let Err(_) = Err::(42) {}\nif let None = None::<()> {}\nif let Some(_) = Some(42) {}\nmatch Ok::(42) {\n Ok(_) => true,\n Err(_) => false,\n};\n```\n\nThe more idiomatic use would be:\n\n```rust\nif Ok::(42).is_ok() {}\nif Err::(42).is_err() {}\nif None::<()>.is_none() {}\nif Some(42).is_some() {}\nOk::(42).is_ok();\n```" + } + }, + { + "id": "redundant_static_lifetimes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for constants and statics with an explicit `'static` lifetime.", + "Why is this bad": "Adding `'static` to every reference can create very\ncomplicated types.", + "Known problems": "None.", + "Example": "```ignore\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```ignore\n const FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n static FOO: &[(&str, &str, fn(&Bar) -> bool)] = &[...]\n```" + } + }, + { + "id": "ref_in_deref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for references in expressions that use\nauto dereference.", + "Why is this bad": "The reference is a no-op and is automatically\ndereferenced by the compiler and makes the code less clear.", + "Example": "```rust\nstruct Point(u32, u32);\nlet point = Point(30, 20);\nlet x = (&point).0;\n```" + } + }, + { + "id": "regex_macro", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `regex!(_)` which (as of now) is\nusually slower than `Regex::new(_)` unless called in a loop (which is a bad\nidea anyway).", + "Why is this bad": "Performance, at least for now. The macro version is\nlikely to catch up long-term, but for now the dynamic version is faster.", + "Known problems": "None.", + "Example": "```ignore\nregex!(\"foo|bar\")\n```" + } + }, + { + "id": "replace_consts", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `ATOMIC_X_INIT`, `ONCE_INIT`, and\n`uX/iX::MIN/MAX`.", + "Why is this bad": "`const fn`s exist", + "Known problems": "None.", + "Example": "```rust\nstatic FOO: AtomicIsize = ATOMIC_ISIZE_INIT;\n```\n\nCould be written:\n\n```rust\nstatic FOO: AtomicIsize = AtomicIsize::new(0);\n```" + } + }, + { + "id": "result_expect_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.expect()` calls on `Result`s.", + "Why is this bad": "`result.expect()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.", + "Known problems": "None.", + "Example": "Using expect on an `Result`:\n\n```rust\nlet res: Result = Ok(1);\nres.expect(\"one\");\n```\n\nBetter:\n\n```\nlet res: Result = Ok(1);\nres?;\n# Ok::<(), ()>(())\n```" + } + }, + { + "id": "result_map_unit_fn", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `result.map(f)` where f is a function\nor closure that returns the unit type.", + "Why is this bad": "Readability, this can be written more clearly with\nan if let statement", + "Known problems": "None.", + "Example": "```rust\nlet x: Result = do_stuff();\nx.map(log_err_msg);\nx.map(|msg| log_err_msg(format_msg(msg)));\n```\n\nThe correct use would be:\n\n```rust\nlet x: Result = do_stuff();\nif let Ok(msg) = x {\n log_err_msg(msg);\n};\nif let Ok(msg) = x {\n log_err_msg(format_msg(msg));\n};\n```" + } + }, + { + "id": "result_map_unwrap_or_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `result.map(_).unwrap_or_else(_)`.", + "Why is this bad": "Readability, this can be written more concisely as\n`result.map_or_else(_, _)`.", + "Known problems": "None.", + "Example": "```rust\nx.map(|a| a + 1).unwrap_or_else(some_function);\n```" + } + }, + { + "id": "result_unwrap_used", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for `.unwrap()` calls on `Result`s.", + "Why is this bad": "`result.unwrap()` will let the thread panic on `Err`\nvalues. Normally, you want to implement more sophisticated error handling,\nand propagate errors upwards with `try!`.\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.", + "Known problems": "None.", + "Example": "Using unwrap on an `Result`:\n\n```rust\nlet res: Result = Ok(1);\nres.unwrap();\n```\n\nBetter:\n\n```rust\nlet res: Result = Ok(1);\nres.expect(\"more helpful message\");\n```" + } + }, + { + "id": "reverse_range_loop", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for loops over ranges `x..y` where both `x` and `y`\nare constant and `x` is greater or equal to `y`, unless the range is\nreversed or has a negative `.step_by(_)`.", + "Why is it bad": "Such loops will either be skipped or loop until\nwrap-around (in debug code, this may `panic!()`). Both options are probably\nnot intended.", + "Known problems": "The lint cannot catch loops over dynamically defined\nranges. Doing this would require simulating all possible inputs and code\npaths through the program, which would be complex and error-prone.", + "Example": "```ignore\nfor x in 5..10 - 5 {\n ..\n} // oops, stray `-`\n```" + } + }, + { + "id": "same_functions_in_if_condition", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for consecutive `if`s with the same function call.", + "Why is this bad": "This is probably a copy & paste error.\nDespite the fact that function can have side effects and `if` works as\nintended, such an approach is implicit and can be considered a \"code smell\".", + "Known problems": "Hopefully none.", + "Example": "```ignore\nif foo() == bar {\n \u2026\n} else if foo() == bar {\n \u2026\n}\n```\n\nThis probably should be:\n```ignore\nif foo() == bar {\n \u2026\n} else if foo() == baz {\n \u2026\n}\n```\n\nor if the original code was not a typo and called function mutates a state,\nconsider move the mutation out of the `if` condition to avoid similarity to\na copy & paste error:\n\n```ignore\nlet first = foo();\nif first == bar {\n \u2026\n} else {\n let second = foo();\n if second == bar {\n \u2026\n }\n}\n```" + } + }, + { + "id": "search_is_some", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for an iterator search (such as `find()`,\n`position()`, or `rposition()`) followed by a call to `is_some()`.", + "Why is this bad": "Readability, this can be written more concisely as\n`_.any(_)`.", + "Known problems": "None.", + "Example": "```rust\nvec.iter().find(|x| **x == 0).is_some();\n```\nCould be written as\n```rust\nvec.iter().any(|x| *x == 0);\n```" + } + }, + { + "id": "serde_api_misuse", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for mis-uses of the serde API.", + "Why is this bad": "Serde is very finnicky about how its API should be\nused, but the type system can't be used to enforce it (yet?).", + "Known problems": "None.", + "Example": "Implementing `Visitor::visit_string` but not\n`Visitor::visit_str`." + } + }, + { + "id": "shadow_reuse", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while reusing the original value.", + "Why is this bad": "Not too much, in fact it's a common pattern in Rust\ncode. Still, some argue that name shadowing like this hurts readability,\nbecause a value may be bound to different things depending on position in\nthe code.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = 2;\nlet x = x + 1;\n```\nuse different variable name:\n```rust\nlet x = 2;\nlet y = x + 1;\n```" + } + }, + { + "id": "shadow_same", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, while just changing reference level or mutability.", + "Why is this bad": "Not much, in fact it's a very common pattern in Rust\ncode. Still, some may opt to avoid it in their code base, they can set this\nlint to `Warn`.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = &x;\n```" + } + }, + { + "id": "shadow_unrelated", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for bindings that shadow other bindings already in\nscope, either without a initialization or with one that does not even use\nthe original value.", + "Why is this bad": "Name shadowing can hurt readability, especially in\nlarge code bases, because it is easy to lose track of the active binding at\nany place in the code. This can be alleviated by either giving more specific\nnames to bindings or introducing more scopes to contain the bindings.", + "Known problems": "This lint, as the other shadowing related lints,\ncurrently only catches very simple patterns.", + "Example": "```rust\nlet x = y;\nlet x = z; // shadows the earlier binding\n```" + } + }, + { + "id": "short_circuit_statement", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of short circuit boolean conditions as\na\nstatement.", + "Why is this bad": "Using a short circuit boolean condition as a statement\nmay hide the fact that the second part is executed or not depending on the\noutcome of the first part.", + "Known problems": "None.", + "Example": "```rust,ignore\nf() && g(); // We should write `if f() { g(); }`.\n```" + } + }, + { + "id": "should_assert_eq", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `assert!(a == b)` and recommend\nreplacement with `assert_eq!(a, b)`, but this is no longer needed after RFC 2011." + } + }, + { + "id": "should_implement_trait", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods that should live in a trait\nimplementation of a `std` trait (see [llogiq's blog\npost](http://llogiq.github.io/2015/07/30/traits.html) for further\ninformation) instead of an inherent implementation.", + "Why is this bad": "Implementing the traits improve ergonomics for users of\nthe code, often with very little cost. Also people seeing a `mul(...)`\nmethod\nmay expect `*` to work equally, so you should have good reason to disappoint\nthem.", + "Known problems": "None.", + "Example": "```ignore\nstruct X;\nimpl X {\n fn add(&self, other: &X) -> X {\n ..\n }\n}\n```" + } + }, + { + "id": "similar_names", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for names that are very similar and thus confusing.", + "Why is this bad": "It's hard to distinguish between names that differ only\nby a single character.", + "Known problems": "None?", + "Example": "```ignore\nlet checked_exp = something;\nlet checked_expr = something_else;\n```" + } + }, + { + "id": "single_char_pattern", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for string methods that receive a single-character\n`str` as an argument, e.g., `_.split(\"x\")`.", + "Why is this bad": "Performing these methods using a `char` is faster than\nusing a `str`.", + "Known problems": "Does not catch multi-byte unicode characters.", + "Example": "`_.split(\"x\")` could be `_.split('x')`" + } + }, + { + "id": "single_match", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for matches with a single arm where an `if let`\nwill usually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "None.", + "Example": "```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => (),\n}\n```" + } + }, + { + "id": "single_match_else", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for matches with two arms where an `if let else` will\nusually suffice.", + "Why is this bad": "Just readability \u2013 `if let` nests less than a `match`.", + "Known problems": "Personal style preferences may differ.", + "Example": "Using `match`:\n\n```rust\nmatch x {\n Some(ref foo) => bar(foo),\n _ => bar(&other_ref),\n}\n```\n\nUsing `if let` with `else`:\n\n```rust\nif let Some(ref foo) = x {\n bar(foo);\n} else {\n bar(&other_ref);\n}\n```" + } + }, + { + "id": "slow_vector_initialization", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks slow zero-filled vector initialization", + "Why is this bad": "These structures are non-idiomatic and less efficient than simply using\n`vec![0; len]`.", + "Known problems": "None.", + "Example": "```rust\nlet mut vec1 = Vec::with_capacity(len);\nvec1.resize(len, 0);\n\nlet mut vec2 = Vec::with_capacity(len);\nvec2.extend(repeat(0).take(len))\n```" + } + }, + { + "id": "str_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `&str`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `to_owned`." + } + }, + { + "id": "string_add", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for all instances of `x + _` where `x` is of type\n`String`, but only if [`string_add_assign`](#string_add_assign) does *not*\nmatch.", + "Why is this bad": "It's not bad in and of itself. However, this particular\n`Add` implementation is asymmetric (the other operand need not be `String`,\nbut `x` does), while addition as mathematically defined is symmetric, also\nthe `String::push_str(_)` function is a perfectly good replacement.\nTherefore, some dislike it and wish not to have it in their code.\n\nThat said, other people think that string addition, having a long tradition\nin other languages is actually fine, which is why we decided to make this\nparticular lint `allow` by default.", + "Known problems": "None.", + "Example": "```rust\nlet x = \"Hello\".to_owned();\nx + \", World\";\n```" + } + }, + { + "id": "string_add_assign", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string appends of the form `x = x + y` (without\n`let`!).", + "Why is this bad": "It's not really bad, but some people think that the\n`.push_str(_)` method is more readable.", + "Known problems": "None.", + "Example": "```rust\nlet mut x = \"Hello\".to_owned();\nx = x + \", World\";\n```" + } + }, + { + "id": "string_extend_chars", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `.extend(s.chars())` where s is a\n`&str` or `String`.", + "Why is this bad": "`.push_str(s)` is clearer", + "Known problems": "None.", + "Example": "```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.extend(abc.chars());\ns.extend(def.chars());\n```\nThe correct use would be:\n```rust\nlet abc = \"abc\";\nlet def = String::from(\"def\");\nlet mut s = String::new();\ns.push_str(abc);\ns.push_str(&def);\n```" + } + }, + { + "id": "string_lit_as_bytes", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for the `as_bytes` method called on string literals\nthat contain only ASCII characters.", + "Why is this bad": "Byte string literals (e.g., `b\"foo\"`) can be used\ninstead. They are shorter but less discoverable than `as_bytes()`.", + "Known Problems": "None.", + "Example": "```rust\nlet bs = \"a byte string\".as_bytes();\n```" + } + }, + { + "id": "string_to_string", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `.to_string()` method calls on values\nof type `String`. This is not unidiomatic and with specialization coming, `to_string` could be\nspecialized to be as efficient as `clone`." + } + }, + { + "id": "suspicious_arithmetic_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of arithmetic operators, e.g.\nsubtracting elements in an Add impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl Add for Foo {\n type Output = Foo;\n\n fn add(self, other: Foo) -> Foo {\n Foo(self.0 - other.0)\n }\n}\n```" + } + }, + { + "id": "suspicious_assignment_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for use of the non-existent `=*`, `=!` and `=-`\noperators.", + "Why is this bad": "This is either a typo of `*=`, `!=` or `-=` or\nconfusing.", + "Known problems": "None.", + "Example": "```rust,ignore\na =- 42; // confusing, should it be `a -= 42` or `a = -42`?\n```" + } + }, + { + "id": "suspicious_else_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for formatting of `else`. It lints if the `else`\nis followed immediately by a newline or the `else` seems to be missing.", + "Why is this bad": "This is probably some refactoring remnant, even if the\ncode is correct, it might look confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo {\n} { // looks like an `else` is missing here\n}\n\nif foo {\n} if bar { // looks like an `else` is missing here\n}\n\nif foo {\n} else\n\n{ // this is the `else` block of the previous `if`, but should it be?\n}\n\nif foo {\n} else\n\nif bar { // this is the `else` block of the previous `if`, but should it be?\n}\n```" + } + }, + { + "id": "suspicious_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calls to `map` followed by a `count`.", + "Why is this bad": "It looks suspicious. Maybe `map` was confused with `filter`.\nIf the `map` call is intentional, this should be rewritten.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).map(|x| x + 2).count();\n```" + } + }, + { + "id": "suspicious_op_assign_impl", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Lints for suspicious operations in impls of OpAssign, e.g.\nsubtracting elements in an AddAssign impl.", + "Why this is bad": "This is probably a typo or copy-and-paste error and not intended.", + "Known problems": "None.", + "Example": "```ignore\nimpl AddAssign for Foo {\n fn add_assign(&mut self, other: Foo) {\n *self = *self - other;\n }\n}\n```" + } + }, + { + "id": "suspicious_unary_op_formatting", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks the formatting of a unary operator on the right hand side\nof a binary operator. It lints if there is no space between the binary and unary operators,\nbut there is a space between the unary and its operand.", + "Why is this bad": "This is either a typo in the binary operator or confusing.", + "Known problems": "None.", + "Example": "```rust,ignore\nif foo <- 30 { // this should be `foo < -30` but looks like a different operator\n}\n\nif foo &&! bar { // this should be `foo && !bar` but looks like a different operator\n}\n```" + } + }, + { + "id": "tabs_in_doc_comments", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks doc comments for usage of tab characters.", + "Why is this bad": "The rust style-guide promotes spaces instead of tabs for indentation.\nTo keep a consistent view on the source, also doc comments should not have tabs.\nAlso, explaining ascii-diagrams containing tabs can get displayed incorrectly when the\ndisplay settings of the author and reader differ.", + "Known problems": "None.", + "Example": "```rust\n///\n/// Struct to hold two strings:\n/// \t- first\t\tone\n/// \t- second\tone\npub struct DoubleString {\n ///\n /// \t- First String:\n /// \t\t- needs to be inside here\n first_string: String,\n ///\n /// \t- Second String:\n /// \t\t- needs to be inside here\n second_string: String,\n}\n```\n\nWill be converted to:\n```rust\n///\n/// Struct to hold two strings:\n/// - first one\n/// - second one\npub struct DoubleString {\n ///\n /// - First String:\n /// - needs to be inside here\n first_string: String,\n ///\n /// - Second String:\n /// - needs to be inside here\n second_string: String,\n}\n```" + } + }, + { + "id": "temporary_assignment", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for construction of a structure or tuple just to\nassign a value in it.", + "Why is this bad": "Readability. If the structure is only created to be\nupdated, why not write the structure you want in the first place?", + "Known problems": "None.", + "Example": "```rust\n(0, 0).0 = 1\n```" + } + }, + { + "id": "temporary_cstring_as_ptr", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for getting the inner pointer of a temporary\n`CString`.", + "Why is this bad": "The inner pointer of a `CString` is only valid as long\nas the `CString` is alive.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap().as_ptr();\nunsafe {\n call_some_ffi_func(c_str);\n}\n```\nHere `c_str` point to a freed address. The correct use would be:\n```rust,ignore\nlet c_str = CString::new(\"foo\").unwrap();\nunsafe {\n call_some_ffi_func(c_str.as_ptr());\n}\n```" + } + }, + { + "id": "to_digit_is_some", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `.to_digit(..).is_some()` on `char`s.", + "Why is this bad": "This is a convoluted way of checking if a `char` is a digit. It's\nmore straight forward to use the dedicated `is_digit` method.", + "Example": "```rust\nlet is_digit = c.to_digit(radix).is_some();\n```\ncan be written as:\n```\n# let c = 'c';\n# let radix = 10;\nlet is_digit = c.is_digit(radix);\n```" + } + }, + { + "id": "todo", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `todo!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```no_run\ntodo!();\n```" + } + }, + { + "id": "too_many_arguments", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for functions with too many parameters.", + "Why is this bad": "Functions with lots of parameters are considered bad\nstyle and reduce readability (\u201cwhat does the 5th parameter mean?\u201d). Consider\ngrouping some parameters into a new type.", + "Known problems": "None.", + "Example": "```rust\nfn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) {\n // ..\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-arguments-threshold: u64`: The maximum number of argument a function or method can have (defaults to `7 `)." + } + }, + { + "id": "too_many_lines", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for functions with a large amount of lines.", + "Why is this bad": "Functions with a lot of lines are harder to understand\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.", + "Known problems": "None.", + "Example": "``` rust\nfn im_too_long() {\nprintln!(\"\");\n// ... 100 more LoC\nprintln!(\"\");\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `too-many-lines-threshold: u64`: The maximum number of lines a function or method can have (defaults to `100 `)." + } + }, + { + "id": "toplevel_ref_arg", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for function arguments and let bindings denoted as\n`ref`.", + "Why is this bad": "The `ref` declaration makes the function take an owned\nvalue, but turns the argument into a reference (which means that the value\nis destroyed when exiting the function). This adds not much value: either\ntake a reference type, or take an owned value and create references in the\nbody.\n\nFor let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The\ntype of `x` is more obvious with the former.", + "Known problems": "If the argument is dereferenced within the function,\nremoving the `ref` will lead to errors. This can be fixed by removing the\ndereferences, e.g., changing `*x` to `x` within the function.", + "Example": "```rust\nfn foo(ref x: u8) -> bool {\n true\n}\n```" + } + }, + { + "id": "transmute_bytes_to_str", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a `&[u8]` to a `&str`.", + "Why is this bad": "Not every byte slice is a valid UTF-8 string.", + "Known problems": "- [`from_utf8`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid UTF-8,\nuse [`from_utf8_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle errors returned from [`from_utf8`] instead of calling `unwrap`.\n\n[`from_utf8`]: https://doc.rust-lang.org/std/str/fn.from_utf8.html\n[`from_utf8_unchecked`]: https://doc.rust-lang.org/std/str/fn.from_utf8_unchecked.html", + "Example": "```rust\nlet b: &[u8] = &[1_u8, 2_u8];\nunsafe {\n let _: &str = std::mem::transmute(b); // where b: &[u8]\n}\n\n// should be:\nlet _ = std::str::from_utf8(b).unwrap();\n```" + } + }, + { + "id": "transmute_float_to_int", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for transmutes from a float to an integer.", + "Why is this bad": "Transmutes are dangerous and error-prone, whereas `to_bits` is intuitive\nand safe.", + "Known problems": "None.", + "Example": "```rust\nunsafe {\n let _: u32 = std::mem::transmute(1f32);\n}\n\n// should be:\nlet _: u32 = 1f32.to_bits();\n```" + } + }, + { + "id": "transmute_int_to_bool", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `bool`.", + "Why is this bad": "This might result in an invalid in-memory representation of a `bool`.", + "Known problems": "None.", + "Example": "```rust\nlet x = 1_u8;\nunsafe {\n let _: bool = std::mem::transmute(x); // where x: u8\n}\n\n// should be:\nlet _: bool = x != 0;\n```" + } + }, + { + "id": "transmute_int_to_char", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a `char`.", + "Why is this bad": "Not every integer is a Unicode scalar value.", + "Known problems": "- [`from_u32`] which this lint suggests using is slower than `transmute`\nas it needs to validate the input.\nIf you are certain that the input is always a valid Unicode scalar value,\nuse [`from_u32_unchecked`] which is as fast as `transmute`\nbut has a semantically meaningful name.\n- You might want to handle `None` returned from [`from_u32`] instead of calling `unwrap`.\n\n[`from_u32`]: https://doc.rust-lang.org/std/char/fn.from_u32.html\n[`from_u32_unchecked`]: https://doc.rust-lang.org/std/char/fn.from_u32_unchecked.html", + "Example": "```rust\nlet x = 1_u32;\nunsafe {\n let _: char = std::mem::transmute(x); // where x: u32\n}\n\n// should be:\nlet _ = std::char::from_u32(x).unwrap();\n```" + } + }, + { + "id": "transmute_int_to_float", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from an integer to a float.", + "Why is this bad": "Transmutes are dangerous and error-prone, whereas `from_bits` is intuitive\nand safe.", + "Known problems": "None.", + "Example": "```rust\nunsafe {\n let _: f32 = std::mem::transmute(1_u32); // where x: u32\n}\n\n// should be:\nlet _: f32 = f32::from_bits(1_u32);\n```" + } + }, + { + "id": "transmute_ptr_to_ptr", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a pointer, or\nfrom a reference to a reference.", + "Why is this bad": "Transmutes are dangerous, and these can instead be\nwritten as casts.", + "Known problems": "None.", + "Example": "```rust\nlet ptr = &1u32 as *const u32;\nunsafe {\n // pointer-to-pointer transmute\n let _: *const f32 = std::mem::transmute(ptr);\n // ref-ref transmute\n let _: &f32 = std::mem::transmute(&1u32);\n}\n// These can be respectively written:\nlet _ = ptr as *const f32;\nlet _ = unsafe{ &*(&1u32 as *const u32 as *const f32) };\n```" + } + }, + { + "id": "transmute_ptr_to_ref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes from a pointer to a reference.", + "Why is this bad": "This can always be rewritten with `&` and `*`.", + "Known problems": "None.", + "Example": "```rust,ignore\nunsafe {\n let _: &T = std::mem::transmute(p); // where p: *const T\n}\n\n// can be written:\nlet _: &T = &*p;\n```" + } + }, + { + "id": "transmuting_null", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmute calls which would receive a null pointer.", + "Why is this bad": "Transmuting a null pointer is undefined behavior.", + "Known problems": "Not all cases can be detected at the moment of this writing.\nFor example, variables which hold a null pointer and are then fed to a `transmute`\ncall, aren't detectable yet.", + "Example": "```rust\nlet null_ref: &u64 = unsafe { std::mem::transmute(0 as *const u64) };\n```" + } + }, + { + "id": "trivial_regex", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for trivial [regex](https://crates.io/crates/regex)\ncreation (with `Regex::new`, `RegexBuilder::new` or `RegexSet::new`).", + "Why is this bad": "Matching the regex can likely be replaced by `==` or\n`str::starts_with`, `str::ends_with` or `std::contains` or other `str`\nmethods.", + "Known problems": "None.", + "Example": "```ignore\nRegex::new(\"^foobar\")\n```" + } + }, + { + "id": "trivially_copy_pass_by_ref", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for functions taking arguments by reference, where\nthe argument type is `Copy` and small enough to be more efficient to always\npass by value.", + "Why is this bad": "In many calling conventions instances of structs will\nbe passed through registers if they fit into two or less general purpose\nregisters.", + "Known problems": "This 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.", + "Example": "```rust\n// Bad\nfn foo(v: &u32) {}\n```\n\n```rust\n// Better\nfn foo(v: u32) {}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `trivial-copy-size-limit: Option`: The maximum size (in bytes) to consider a `Copy` type for passing by value instead of by reference. (defaults to `None `)." + } + }, + { + "id": "try_err", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for usages of `Err(x)?`.", + "Why is this bad": "The `?` operator is designed to allow calls that\ncan fail to be easily chained. For example, `foo()?.bar()` or\n`foo(bar()?)`. Because `Err(x)?` can't be used that way (it will\nalways return), it is more clear to write `return Err(x)`.", + "Known problems": "None.", + "Example": "```rust\nfn foo(fail: bool) -> Result {\n if fail {\n Err(\"failed\")?;\n }\n Ok(0)\n}\n```\nCould be written:\n\n```rust\nfn foo(fail: bool) -> Result {\n if fail {\n return Err(\"failed\".into());\n }\n Ok(0)\n}\n```" + } + }, + { + "id": "type_complexity", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for types used in structs, parameters and `let`\ndeclarations above a certain complexity threshold.", + "Why is this bad": "Too complex types make the code less readable. Consider\nusing a `type` definition to simplify them.", + "Known problems": "None.", + "Example": "```rust\nstruct Foo {\n inner: Rc>>>,\n}\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `type-complexity-threshold: u64`: The maximum complexity a type can have (defaults to `250 `)." + } + }, + { + "id": "type_repetition_in_bounds", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "This lint warns about unnecessary type repetitions in trait bounds", + "Why is this bad": "Repeating the type for every bound makes the code\nless readable than combining the bounds", + "Example": "```rust\npub fn foo(t: T) where T: Copy, T: Clone {}\n```\n\nCould be written as:\n\n```rust\npub fn foo(t: T) where T: Copy + Clone {}\n```" + } + }, + { + "id": "unicode_not_nfc", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for string literals that contain Unicode in a form\nthat is not equal to its\n[NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).", + "Why is this bad": "If such a string is compared to another, the results\nmay be surprising.", + "Known problems": "None.", + "Example": "You may not see it, but \"a\u0300\"\" and \"\u00e0\"\" aren't the same string. The\nformer when escaped is actually `\"a\\u{300}\"` while the latter is `\"\\u{e0}\"`." + } + }, + { + "id": "unimplemented", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unimplemented!`.", + "Why is this bad": "This macro should not be present in production code", + "Known problems": "None.", + "Example": "```no_run\nunimplemented!();\n```" + } + }, + { + "id": "uninit_assumed_init", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `MaybeUninit::uninit().assume_init()`.", + "Why is this bad": "For most types, this is undefined behavior.", + "Known problems": "For now, we accept empty tuples and tuples / arrays\nof `MaybeUninit`. There may be other types that allow uninitialized\ndata, but those are not yet rigorously defined.", + "Example": "```rust\n// Beware the UB\nuse std::mem::MaybeUninit;\n\nlet _: usize = unsafe { MaybeUninit::uninit().assume_init() };\n```\n\nNote that the following is OK:\n\n```rust\nuse std::mem::MaybeUninit;\n\nlet _: [MaybeUninit; 5] = unsafe {\n MaybeUninit::uninit().assume_init()\n};\n```" + } + }, + { + "id": "unit_arg", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for passing a unit value as an argument to a function without using a\nunit literal (`()`).", + "Why is this bad": "This is likely the result of an accidental semicolon.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo({\n let a = bar();\n baz(a);\n})\n```" + } + }, + { + "id": "unit_cmp", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for comparisons to unit. This includes all binary\ncomparisons (like `==` and `<`) and asserts.", + "Why is this bad": "Unit is always equal to itself, and thus is just a\nclumsily written constant. Mostly this happens when someone accidentally\nadds semicolons at the end of the operands.", + "Known problems": "None.", + "Example": "```rust\nif {\n foo();\n} == {\n bar();\n} {\n baz();\n}\n```\nis equal to\n```rust\n{\n foo();\n bar();\n baz();\n}\n```\n\nFor asserts:\n```rust\nassert_eq!({ foo(); }, { bar(); });\n```\nwill always succeed" + } + }, + { + "id": "unknown_clippy_lints", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `allow`/`warn`/`deny`/`forbid` attributes with scoped clippy\nlints and if those lints exist in clippy. If there is an uppercase letter in the lint name\n(not the tool name) and a lowercase version of this lint exists, it will suggest to lowercase\nthe lint name.", + "Why is this bad": "A lint attribute with a mistyped lint name won't have an effect.", + "Known problems": "None.", + "Example": "Bad:\n```rust\n#![warn(if_not_els)]\n#![deny(clippy::All)]\n```\n\nGood:\n```rust\n#![warn(if_not_else)]\n#![deny(clippy::all)]\n```" + } + }, + { + "id": "unnecessary_cast", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for casts to the same type.", + "Why is this bad": "It's just unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet _ = 2i32 as i32;\n```" + } + }, + { + "id": "unnecessary_filter_map", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `filter_map` calls which could be replaced by `filter` or `map`.\nMore specifically it checks if the closure provided is only performing one of the\nfilter or map operations and suggests the appropriate option.", + "Why is this bad": "Complexity. The intent is also clearer if only a single\noperation is being performed.", + "Known problems": "None", + "Example": "```rust\nlet _ = (0..3).filter_map(|x| if x > 2 { Some(x) } else { None });\n```\nAs there is no transformation of the argument this could be written as:\n```rust\nlet _ = (0..3).filter(|&x| x > 2);\n```\n\n```rust\nlet _ = (0..4).filter_map(i32::checked_abs);\n```\nAs there is no conditional check on the argument this could be written as:\n```rust\nlet _ = (0..4).map(i32::checked_abs);\n```" + } + }, + { + "id": "unnecessary_fold", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for using `fold` when a more succinct alternative exists.\nSpecifically, this checks for `fold`s which could be replaced by `any`, `all`,\n`sum` or `product`.", + "Why is this bad": "Readability.", + "Known problems": "False positive in pattern guards. Will be resolved once\nnon-lexical lifetimes are stable.", + "Example": "```rust\nlet _ = (0..3).fold(false, |acc, x| acc || x > 2);\n```\nThis could be written as:\n```rust\nlet _ = (0..3).any(|x| x > 2);\n```" + } + }, + { + "id": "unnecessary_mut_passed", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Detects giving a mutable reference to a function that only\nrequires an immutable reference.", + "Why is this bad": "The immutable reference rules out all other references\nto the value. Also the code misleads about the intent of the call site.", + "Known problems": "None.", + "Example": "```ignore\nmy_vec.push(&mut value)\n```" + } + }, + { + "id": "unnecessary_operation", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for expression statements that can be reduced to a\nsub-expression.", + "Why is this bad": "Expressions by themselves often have no side-effects.\nHaving such expressions reduces readability.", + "Known problems": "None.", + "Example": "```rust,ignore\ncompute_array()[0];\n```" + } + }, + { + "id": "unnecessary_unwrap", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for calls of `unwrap[_err]()` that cannot fail.", + "Why is this bad": "Using `if let` or `match` is more idiomatic.", + "Known problems": "None", + "Example": "```rust\nif option.is_some() {\n do_something_with(option.unwrap())\n}\n```\n\nCould be written:\n\n```rust\nif let Some(value) = option {\n do_something_with(value)\n}\n```" + } + }, + { + "id": "unneeded_field_pattern", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for structure field patterns bound to wildcards.", + "Why is this bad": "Using `..` instead is shorter and leaves the focus on\nthe fields that are actually bound.", + "Known problems": "None.", + "Example": "```ignore\nlet { a: _, b: ref b, c: _ } = ..\n```" + } + }, + { + "id": "unneeded_wildcard_pattern", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for tuple patterns with a wildcard\npattern (`_`) is next to a rest pattern (`..`).\n\n_NOTE_: While `_, ..` means there is at least one element left, `..`\nmeans there are 0 or more elements left. This can make a difference\nwhen refactoring, but shouldn't result in errors in the refactored code,\nsince the wildcard pattern isn't used anyway.", + "Why is this bad": "The wildcard pattern is unneeded as the rest pattern\ncan match that element as well.", + "Known problems": "None.", + "Example": "```rust\n\nmatch t {\n TupleStruct(0, .., _) => (),\n _ => (),\n}\n```\ncan be written as\n```rust\n\nmatch t {\n TupleStruct(0, ..) => (),\n _ => (),\n}\n```" + } + }, + { + "id": "unreachable", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for usage of `unreachable!`.", + "Why is this bad": "This macro can cause code to panic", + "Known problems": "None.", + "Example": "```no_run\nunreachable!();\n```" + } + }, + { + "id": "unreadable_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Warns if a long integral or floating-point constant does\nnot contain underscores.", + "Why is this bad": "Reading long numbers is difficult without separators.", + "Known problems": "None.", + "Example": "```rust\nlet x: u64 = 61864918973511;\n```" + } + }, + { + "id": "unsafe_removed_from_name", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for imports that remove \"unsafe\" from an item's\nname.", + "Why is this bad": "Renaming makes it less clear which traits and\nstructures are unsafe.", + "Known problems": "None.", + "Example": "```rust,ignore\nuse std::cell::{UnsafeCell as TotallySafeCell};\n\nextern crate crossbeam;\nuse crossbeam::{spawn_unsafe as spawn};\n```" + } + }, + { + "id": "unsafe_vector_initialization", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint used to suggest replacing `let mut vec =\nVec::with_capacity(n); vec.set_len(n);` with `let vec = vec![0; n];`. The\nreplacement has very different performance characteristics so the lint is\ndeprecated." + } + }, + { + "id": "unseparated_literal_suffix", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Warns if literal suffixes are not separated by an\nunderscore.", + "Why is this bad": "It is much less readable.", + "Known problems": "None.", + "Example": "```rust\nlet y = 123832i32;\n```" + } + }, + { + "id": "unsound_collection_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes between collections whose\ntypes have different ABI, size or alignment.", + "Why is this bad": "This is undefined behavior.", + "Known problems": "Currently, we cannot know whether a type is a\ncollection, so we just lint the ones that come with `std`.", + "Example": "```rust\n// different size, therefore likely out-of-bounds memory access\n// You absolutely do not want this in your code!\nunsafe {\n std::mem::transmute::<_, Vec>(vec![2_u16])\n};\n```\n\nYou must always iterate, map and collect the values:\n\n```rust\nvec![2_u16].into_iter().map(u32::from).collect::>();\n```" + } + }, + { + "id": "unstable_as_mut_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_mut_slice`, which was unstable with good\nstable alternatives. `Vec::as_mut_slice` has now been stabilized." + } + }, + { + "id": "unstable_as_slice", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This used to check for `Vec::as_slice`, which was unstable with good\nstable alternatives. `Vec::as_slice` has now been stabilized." + } + }, + { + "id": "unused_collect", + "group": "deprecated", + "level": "Deprecated", + "docs": { + "What it does": "Nothing. This lint has been deprecated.", + "Deprecation reason": "This lint has been superseded by #[must_use] in rustc." + } + }, + { + "id": "unused_io_amount", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for unused written/read amount.", + "Why is this bad": "`io::Write::write` and `io::Read::read` are not\nguaranteed to\nprocess the entire buffer. They return how many bytes were processed, which\nmight be smaller\nthan a given buffer's length. If you don't need to deal with\npartial-write/read, use\n`write_all`/`read_exact` instead.", + "Known problems": "Detects only common patterns.", + "Example": "```rust,ignore\nuse std::io;\nfn foo(w: &mut W) -> io::Result<()> {\n // must be `w.write_all(b\"foo\")?;`\n w.write(b\"foo\")?;\n Ok(())\n}\n```" + } + }, + { + "id": "unused_label", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for unused labels.", + "Why is this bad": "Maybe the label should be used in which case there is\nan error in the code or it should be removed.", + "Known problems": "Hopefully none.", + "Example": "```rust,ignore\nfn unused_label() {\n 'label: for i in 1..2 {\n if i > 4 { continue }\n }\n```" + } + }, + { + "id": "unused_self", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks methods that contain a `self` argument but don't use it", + "Why is this bad": "It may be clearer to define the method as an associated function instead\nof an instance method if it doesn't require `self`.", + "Known problems": "None.", + "Example": "```rust,ignore\nstruct A;\nimpl A {\n fn method(&self) {}\n}\n```\n\nCould be written:\n\n```rust,ignore\nstruct A;\nimpl A {\n fn method() {}\n}\n```" + } + }, + { + "id": "unused_unit", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for unit (`()`) expressions that can be removed.", + "Why is this bad": "Such expressions add no value, but can make the code\nless readable. Depending on formatting they can make a `break` or `return`\nstatement look like a function call.", + "Known problems": "The lint currently misses unit return types in types,\ne.g., the `F` in `fn generic_unit ()>(f: F) { .. }`.", + "Example": "```rust\nfn return_unit() -> () {\n ()\n}\n```" + } + }, + { + "id": "use_debug", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for use of `Debug` formatting. The purpose of this\nlint is to catch debugging remnants.", + "Why is this bad": "The purpose of the `Debug` trait is to facilitate\ndebugging Rust code. It should not be used in user-facing output.", + "Example": "```rust\nprintln!(\"{:?}\", foo);\n```" + } + }, + { + "id": "use_self", + "group": "nursery", + "level": "Allow", + "docs": { + "What it does": "Checks for unnecessary repetition of structure name when a\nreplacement with `Self` is applicable.", + "Why is this bad": "Unnecessary repetition. Mixed use of `Self` and struct\nname\nfeels inconsistent.", + "Known problems": "- False positive when using associated types (#2843)\n- False positives in some situations when using generics (#3410)", + "Example": "```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```" + } + }, + { + "id": "used_underscore_binding", + "group": "pedantic", + "level": "Allow", + "docs": { + "What it does": "Checks for the use of bindings with a single leading\nunderscore.", + "Why is this bad": "A single leading underscore is usually used to indicate\nthat a binding will not be used. Using such a binding breaks this\nexpectation.", + "Known problems": "The lint does not work properly with desugaring and\nmacro, it has been allowed in the mean time.", + "Example": "```rust\nlet _x = 0;\nlet y = _x + 1; // Here we are using `_x`, even though it has a leading\n // underscore. We should rename `_x` to `x`\n```" + } + }, + { + "id": "useless_asref", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `.as_ref()` or `.as_mut()` where the\ntypes before and after the call are the same.", + "Why is this bad": "The call is unnecessary.", + "Known problems": "None.", + "Example": "```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x.as_ref());\n```\nThe correct use would be:\n```rust\nlet x: &[i32] = &[1, 2, 3, 4, 5];\ndo_stuff(x);\n```" + } + }, + { + "id": "useless_attribute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `extern crate` and `use` items annotated with\nlint attributes.\n\nThis lint whitelists `#[allow(unused_imports)]`, `#[allow(deprecated)]` and\n`#[allow(unreachable_pub)]` on `use` items and `#[allow(unused_imports)]` on\n`extern crate` items with a `#[macro_use]` attribute.", + "Why is this bad": "Lint attributes have no effect on crate imports. Most\nlikely a `!` was forgotten.", + "Known problems": "None.", + "Example": "```ignore\n// Bad\n#[deny(dead_code)]\nextern crate foo;\n#[forbid(dead_code)]\nuse foo::bar;\n\n// Ok\n#[allow(unused_imports)]\nuse foo::baz;\n#[allow(unused_imports)]\n#[macro_use]\nextern crate baz;\n```" + } + }, + { + "id": "useless_format", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for the use of `format!(\"string literal with no\nargument\")` and `format!(\"{}\", foo)` where `foo` is a string.", + "Why is this bad": "There is no point of doing that. `format!(\"foo\")` can\nbe replaced by `\"foo\".to_owned()` if you really need a `String`. The even\nworse `&format!(\"foo\")` is often encountered in the wild. `format!(\"{}\",\nfoo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`\nif `foo: &str`.", + "Known problems": "None.", + "Examples": "```rust\nformat!(\"foo\");\nformat!(\"{}\", foo);\n```" + } + }, + { + "id": "useless_let_if_seq", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for variable declarations immediately followed by a\nconditional affectation.", + "Why is this bad": "This is not idiomatic Rust.", + "Known problems": "None.", + "Example": "```rust,ignore\nlet foo;\n\nif bar() {\n foo = 42;\n} else {\n foo = 0;\n}\n\nlet mut baz = None;\n\nif bar() {\n baz = Some(42);\n}\n```\n\nshould be written\n\n```rust,ignore\nlet foo = if bar() {\n 42\n} else {\n 0\n};\n\nlet baz = if bar() {\n Some(42)\n} else {\n None\n};\n```" + } + }, + { + "id": "useless_transmute", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for transmutes to the original type of the object\nand transmutes that could be a cast.", + "Why is this bad": "Readability. The code tricks people into thinking that\nsomething complex is going on.", + "Known problems": "None.", + "Example": "```rust,ignore\ncore::intrinsics::transmute(t); // where the result type is the same as `t`'s\n```" + } + }, + { + "id": "useless_vec", + "group": "perf", + "level": "Warn", + "docs": { + "What it does": "Checks for usage of `&vec![..]` when using `&[..]` would\nbe possible.", + "Why is this bad": "This is less efficient.", + "Known problems": "None.", + "Example": "```rust,ignore\nfoo(&vec![1, 2])\n```" + } + }, + { + "id": "vec_box", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for use of `Vec>` where T: Sized anywhere in the code.", + "Why is this bad": "`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.", + "Known problems": "Vec> makes sense if T is a large type (see #3530,\n1st comment).", + "Example": "```rust\nstruct X {\n values: Vec>,\n}\n```\n\nBetter:\n\n```rust\nstruct X {\n values: Vec,\n}\n```" + } + }, + { + "id": "verbose_bit_mask", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for bit masks that can be replaced by a call\nto `trailing_zeros`", + "Why is this bad": "`x.trailing_zeros() > 4` is much clearer than `x & 15\n== 0`", + "Known problems": "llvm generates better code for `x & 15 == 0` on x86", + "Example": "```rust\nif x & 0x1111 == 0 { }\n```", + "Configuration": "This lint has the following configuration variables:\n\n* `verbose-bit-mask-threshold: u64`: The maximum allowed size of a bit mask before suggesting to use 'trailing_zeros' (defaults to `1 `)." + } + }, + { + "id": "while_immutable_condition", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks whether variables used within while loop condition\ncan be (and are) mutated in the body.", + "Why is this bad": "If the condition is unchanged, entering the body of the loop\nwill lead to an infinite loop.", + "Known problems": "If the `while`-loop is in a closure, the check for mutation of the\ncondition variables in the body can cause false negatives. For example when only `Upvar` `a` is\nin the condition and only `Upvar` `b` gets mutated in the body, the lint will not trigger.", + "Example": "```rust\nlet i = 0;\nwhile i > 10 {\n println!(\"let me loop forever!\");\n}\n```" + } + }, + { + "id": "while_let_loop", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Detects `loop + match` combinations that are easier\nwritten as a `while let` loop.", + "Why is this bad": "The `while let` loop is usually shorter and more\nreadable.", + "Known problems": "Sometimes the wrong binding is displayed (#383).", + "Example": "```rust,no_run\nloop {\n let x = match y {\n Some(x) => x,\n None => break,\n };\n // .. do something with x\n}\n// is easier written as\nwhile let Some(x) = y {\n // .. do something with x\n};\n```" + } + }, + { + "id": "while_let_on_iterator", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for `while let` expressions on iterators.", + "Why is this bad": "Readability. A simple `for` loop is shorter and conveys\nthe intent better.", + "Known problems": "None.", + "Example": "```ignore\nwhile let Some(val) = iter() {\n ..\n}\n```" + } + }, + { + "id": "wildcard_dependencies", + "group": "cargo", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard dependencies in the `Cargo.toml`.", + "Why is this bad": "[As the edition guide says](https://rust-lang-nursery.github.io/edition-guide/rust-2018/cargo-and-crates-io/crates-io-disallows-wildcard-dependencies.html),\nit is highly unlikely that you work with any possible version of your dependency,\nand wildcard dependencies would cause unnecessary breakage in the ecosystem.", + "Known problems": "None.", + "Example": "```toml\n[dependencies]\nregex = \"*\"\n```" + } + }, + { + "id": "wildcard_enum_match_arm", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "Checks for wildcard enum matches using `_`.", + "Why is this bad": "New enum variants added by library updates can be missed.", + "Known problems": "Suggested replacements may be incorrect if guards exhaustively cover some\nvariants, and also may not use correct path to enum if it's not present in the current scope.", + "Example": "```rust\nmatch x {\n A => {},\n _ => {},\n}\n```" + } + }, + { + "id": "write_literal", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns about the use of literals as `write!`/`writeln!` args.", + "Why is this bad": "Using literals as `writeln!` args is inefficient\n(c.f., https://github.com/matthiaskrgr/rust-str-bench) and unnecessary\n(i.e., just put the literal in the format string)", + "Known problems": "Will also warn with macro calls as arguments that expand to literals\n-- e.g., `writeln!(buf, \"{}\", env!(\"FOO\"))`.", + "Example": "```rust\nwriteln!(buf, \"{}\", \"foo\");\n```" + } + }, + { + "id": "write_with_newline", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `write!()` with a format\nstring that\nends in a newline.", + "Why is this bad": "You should use `writeln!()` instead, which appends the\nnewline.", + "Known problems": "None.", + "Example": "```rust\nwrite!(buf, \"Hello {}!\\n\", name);\n```" + } + }, + { + "id": "writeln_empty_string", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "This lint warns when you use `writeln!(buf, \"\")` to\nprint a newline.", + "Why is this bad": "You should use `writeln!(buf)`, which is simpler.", + "Known problems": "None.", + "Example": "```rust\nwriteln!(buf, \"\");\n```" + } + }, + { + "id": "wrong_pub_self_convention", + "group": "restriction", + "level": "Allow", + "docs": { + "What it does": "This is the same as\n[`wrong_self_convention`](#wrong_self_convention), but for public items.", + "Why is this bad": "See [`wrong_self_convention`](#wrong_self_convention).", + "Known problems": "Actually *renaming* the function may break clients if\nthe function is part of the public interface. In that case, be mindful of\nthe stability guarantees you've given your users.", + "Example": "```rust\nimpl<'a> X {\n pub fn as_str(self) -> &'a str {\n \"foo\"\n }\n}\n```" + } + }, + { + "id": "wrong_self_convention", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Checks for methods with certain name prefixes and which\ndoesn't match how self is taken. The actual rules are:\n\n|Prefix |`self` taken |\n|-------|----------------------|\n|`as_` |`&self` or `&mut self`|\n|`from_`| none |\n|`into_`|`self` |\n|`is_` |`&self` or none |\n|`to_` |`&self` |", + "Why is this bad": "Consistency 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.", + "Known problems": "None.", + "Example": "```ignore\nimpl X {\n fn as_str(self) -> &str {\n ..\n }\n}\n```" + } + }, + { + "id": "wrong_transmute", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for transmutes that can't ever be correct on any\narchitecture.", + "Why is this bad": "It's basically guaranteed to be undefined behaviour.", + "Known problems": "When accessing C, users might want to store pointer\nsized objects in `extradata` arguments to save an allocation.", + "Example": "```ignore\nlet ptr: *const T = core::intrinsics::transmute('x')\n```" + } + }, + { + "id": "zero_divided_by_zero", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Checks for `0.0 / 0.0`.", + "Why is this bad": "It's less readable than `std::f32::NAN` or\n`std::f64::NAN`.", + "Known problems": "None.", + "Example": "```rust\n0.0f32 / 0.0;\n```" + } + }, + { + "id": "zero_prefixed_literal", + "group": "complexity", + "level": "Warn", + "docs": { + "What it does": "Warns if an integral constant literal starts with `0`.", + "Why is this bad": "In some languages (including the infamous C language\nand most of its\nfamily), this marks an octal constant. In Rust however, this is a decimal\nconstant. This could\nbe confusing for both the writer and a reader of the constant.", + "Known problems": "None.", + "Example": "In Rust:\n```rust\nfn main() {\n let a = 0123;\n println!(\"{}\", a);\n}\n```\n\nprints `123`, while in C:\n\n```c\n#include \n\nint main() {\n int a = 0123;\n printf(\"%d\\n\", a);\n}\n```\n\nprints `83` (as `83 == 0o123` while `123 == 0o173`)." + } + }, + { + "id": "zero_ptr", + "group": "style", + "level": "Warn", + "docs": { + "What it does": "Catch casts from `0` to some pointer type", + "Why is this bad": "This generally means `null` and is better expressed as\n{`std`, `core`}`::ptr::`{`null`, `null_mut`}.", + "Known problems": "None.", + "Example": "```rust\nlet a = 0 as *const u32;\n```" + } + }, + { + "id": "zero_width_space", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for the Unicode zero-width space in the code.", + "Why is this bad": "Having an invisible character in the code makes for all\nsorts of April fools, but otherwise is very much frowned upon.", + "Known problems": "None.", + "Example": "You don't see it, but there may be a zero-width space\nsomewhere in this text." + } + }, + { + "id": "zst_offset", + "group": "correctness", + "level": "Deny", + "docs": { + "What it does": "Checks for `offset(_)`, `wrapping_`{`add`, `sub`}, etc. on raw pointers to\nzero-sized types", + "Why is this bad": "This is a no-op, and likely unintended", + "Known problems": "None", + "Example": "```ignore\nunsafe { (&() as *const ()).offset(1) };\n```" + } + } +] \ No newline at end of file diff --git a/stable b/stable new file mode 120000 index 000000000000..e6c8f6728a83 --- /dev/null +++ b/stable @@ -0,0 +1 @@ +rust-1.41.0 \ No newline at end of file diff --git a/versions.json b/versions.json index 093ec80d82df..877bf2d6afd4 100644 --- a/versions.json +++ b/versions.json @@ -1 +1 @@ -["v0.0.91", "v0.0.150", "v0.0.189", "v0.0.171", "v0.0.209", "v0.0.204", "v0.0.155", "v0.0.199", "v0.0.181", "v0.0.149", "v0.0.95", "v0.0.159", "v0.0.211", "master", "v0.0.207", "v0.0.212", "v0.0.201", "v0.0.179", "v0.0.142", "v0.0.97", "0.0.125", "v0.0.137", "v0.0.157", "v0.0.162", "v0.0.108", "v0.0.103", "v0.0.84", "v0.0.184", "v0.0.164", "v0.0.151", "v0.0.140", "v0.0.106", "v0.0.205", "v0.0.194", "v0.0.173", "v0.0.187", "v0.0.147", "v0.0.100", "v0.0.158", "v0.0.193", "v0.0.208", "v0.0.161", "v0.0.188", "v0.0.175", "v0.0.118", "v0.0.94", "v0.0.180", "v0.0.202", "v0.0.163", "v0.0.178", "v0.0.90", "v0.0.165", "v0.0.131", "v0.0.101", "v0.0.190", "v0.0.89", "v0.0.116", "v0.0.114", "v0.0.88", "v0.0.174", "v0.0.196", "v0.0.185", "v0.0.92", "0.0.129", "0.0.136", "v0.0.98", "v0.0.93", "v0.0.99", "v0.0.156", "v0.0.210", "list", "v0.0.166", "v0.0.154", "v0.0.192", "current", "v0.0.83", "v0.0.86", "v0.0.176", "v0.0.168", "v0.0.145", "v0.0.138", "v0.0.160", "v0.0.121", "v0.0.87", "v0.0.105", "v0.0.177", "v0.0.85", "v0.0.191", "v0.0.104", "v0.0.198", "v0.0.172", "v0.0.200", "v0.0.186", "v0.0.102", "0.0.124", "0.0.90", "v0.0.130", "v0.0.197", "v0.0.109", "v0.0.203", "v0.0.96"] +["v0.0.100", "v0.0.101", "v0.0.102", "v0.0.103", "v0.0.104", "v0.0.105", "v0.0.106", "v0.0.108", "v0.0.109", "v0.0.114", "v0.0.116", "v0.0.118", "v0.0.121", "0.0.124", "0.0.125", "0.0.129", "v0.0.130", "v0.0.131", "0.0.136", "v0.0.137", "v0.0.138", "v0.0.140", "v0.0.142", "v0.0.145", "v0.0.147", "v0.0.149", "v0.0.150", "v0.0.151", "v0.0.154", "v0.0.155", "v0.0.156", "v0.0.157", "v0.0.158", "v0.0.159", "v0.0.160", "v0.0.161", "v0.0.162", "v0.0.163", "v0.0.164", "v0.0.165", "v0.0.166", "v0.0.168", "v0.0.171", "v0.0.172", "v0.0.173", "v0.0.174", "v0.0.175", "v0.0.176", "v0.0.177", "v0.0.178", "v0.0.179", "v0.0.180", "v0.0.181", "v0.0.184", "v0.0.185", "v0.0.186", "v0.0.187", "v0.0.188", "v0.0.189", "v0.0.190", "v0.0.191", "v0.0.192", "v0.0.193", "v0.0.194", "v0.0.196", "v0.0.197", "v0.0.198", "v0.0.199", "v0.0.200", "v0.0.201", "v0.0.202", "v0.0.203", "v0.0.204", "v0.0.205", "v0.0.207", "v0.0.208", "v0.0.209", "v0.0.210", "v0.0.211", "v0.0.212", "v0.0.83", "v0.0.84", "v0.0.85", "v0.0.86", "v0.0.87", "v0.0.88", "v0.0.89", "0.0.90", "v0.0.90", "v0.0.91", "v0.0.92", "v0.0.93", "v0.0.94", "v0.0.95", "v0.0.96", "v0.0.97", "v0.0.98", "v0.0.99", "current", "master", "rust-1.29.0", "rust-1.29.1", "rust-1.29.2", "rust-1.30.0", "rust-1.30.1", "rust-1.31.0", "rust-1.31.1", "rust-1.32.0", "rust-1.33.0", "rust-1.34.0", "rust-1.34.1", "rust-1.34.2", "rust-1.35.0", "rust-1.36.0", "rust-1.37.0", "rust-1.38.0", "rust-1.39.0", "rust-1.40.0", "rust-1.41.0"]