This lint detects inefficient or useless `{std,core}::mem::swap()` calls
such as:
```rust
// Should be `a = temp();`
swap(&mut a, &mut temp());
// Should be `*b = temp();`
swap(b, &mut temp());
// Should be `temp1(); temp2();` if we want to keep the side effects
swap(&mut temp1(), &mut temp2());
```
It also takes care of using a form appropriate for a `()` context if
`swap()` is part of a larger expression (don't ask me why this wouldn't
happen, I have no idea), by suggesting `{ x = y; }` (statement in block)
or `{std,core}::mem::drop((temp1(), temp2())`.
changelog: [`swap_with_temporary`]: new lint
Close#1968
- Do not replace macro results in then/else branches
- Extract condition snippet from the right context
- Make suggestion `MaybeIncorrect` if it would lead to losing comments
changelog: [`bool_to_int_with_if`]: properly handle macros
Fixesrust-lang/rust-clippy#14628
Instead of looking for angle brackets in the source code, use the HIR
and Ty interfaces to either copy the original type, or complete it with
`_` placeholders if all type and const generic arguments are inferred.
Fixesrust-lang/rust-clippy#14581
changelog: [`from_iter_instead_of_collect`]: show correct type in
suggestion
- Do not replace macro results in then/else branches
- Extract condition snippet from the right context
- Make suggestion `MaybeIncorrect` if it would lead to losing comments
This PR has started as an effort to proceed from the feedback in
rust-lang/rust-clippy#12861.
- Checks test functions (functions marked with `#[test]` annotation) for
redundant "test_" prefix.
- Auto-fix is supported (and handles collisions gracefully, see below).
- If removing "test_" prefix from, say, `test_foo()` results in a name
collision (either because function `foo()` is already defined within the
current scope, or because the `foo()` call exists within function --
thus creating an unwanted recursion), lint suggests function rename,
warning the user that a simple trimming of `test_` prefix will result in
a name collision.
- If removing "test_" prefix results in invalid identifier (consider
`test_const`, `test_`, `test_42`), then again no auto-fix is suggested,
user is asked to rename function, with a note that a simple prefix
trimming will result in an invalid function name.
(`Applicability::HasPlaceholders` is used and user is suggested to: drop
`test_` prefix + add `_works` suffix, i.e. `test_foo` becomes
`foo_works` -- but again, user has to apply those changes manually).
- If trimmed version of the function name is a valid identifier, doesn't
result in name collision or unwanted recursion, then user is able to run
auto-fix.
fixesrust-lang/rust-clippy#8931
changelog: new lint: [`redundant_test_prefix`]
To avoid crashing Clippy, the `bug!()` is used only when debug
assertions are enabled. In regular usage, the result will be the same as
before, but without the extra line printed on the standard output which
has the potential for disrupting shell scripts.
changelog: none
In edition 2024, `unsafe` blocks must be used inside `unsafe fn` to do
unsafe things. The `misnamed_getters` would not lint if the getter
expression was embedded inside an `unsafe` block.
`assert_eq!()` and `assert_ne!()` are not expanded the same way as
`assert!()` (they use a `match` instead of a `if`). This makes them
being recognized as well.
Fixrust-lang/rust-clippy#14255
changelog: [`missing_asserts_for_indexing`]: consider `assert_eq!()` as
well
To avoid crashing Clippy, the `bug!()` is used only when debug assertions are
enabled. In regular usage, the result will be the same as before, but without
the extra line printed on the standard output which has the potential for
disrupting shell scripts.
fixes#7749.
This issue proposes searching for `DerefMut` impls, which is not done
here: every lifetime parameter (aka `<'a>`) is the input types is
considered to be potentially mutable, and thus deactivates the lint.
changelog: [`mut_from_ref`]: Fixes false positive, where lifetimes
nested in the type (e.g. `Box<&'a mut T>`) were not considered.
Fix#14461:
- insert parentheses as required in suggestion
- check MSRV before suggesting fix in `const` context
- do not lint macro expansion result
Commits have been logically separated to facilitate review, and start
with a refactoring (and simplification) of the existing code.
changelog: [`manual_is_power_of_two`]: insert parentheses as required in
suggestion, check MSRV before suggesting fix in `const` context, do not
lint macro expansion results
`clippy::len_without_is_empty` can be allowed at the type declaration
site, and this will prevent the lint from triggering even though the
lint is shown on the `len()` method definition.
This allows the lint to be expected even though it is allowed at the
type declaration site.
changelog: [`len_without_is_empty`]: the lint can now be `#[expect]`ed
on the `len()` method even when it is `#[allow]`ed on the definining
type.
Fixesrust-lang/rust-clippy#14597
`clippy::len_without_is_empty` can be allowed at the type declaration
site, and this will prevent the lint from triggering even though the
lint is shown on the `len()` method definition.
This allows the lint to be expected even though it is allowed at the
type declaration site.
This lint does more harm than good: in its description, it proposes to
rewrite `match` on `Vec<_>` indexes or slices by a version which cannot
panic but masks the failure by choosing the default variant.
The `clippy::indexing_slicing` restriction lint covers those cases more
safely, by suggesting to use a non-panicking version to retrieve the
value from the container, without suggesting to fallback to the default
success variant in case of failure.
This PR is an (opposite) alternative to #14208 (which will add a
suggestion to the lint matching the lint description). Discussion on
both PRs can be found [on
Zulip](https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/Suggestions.20that.20suppress.20panics).
changelog: [`match_on_vec_items`]: deprecate lint
`unsafe_fields` is an incomplete feature; comments have been put near
`#![expect(incomplete_features)]` to ensure that we revisit the
situation when the feature becomes complete.
changelog: [`expl_impl_clone_on_copy`]: do not lint in the presence of
`unsafe` fields
Fixes#14558
Blocks created by desugaring will not contain an explicit `return`. Do
not suggest to add it when the user has no control over the desugared
code.
Also, ensure that in a `xxx.await` expression, the suggested `return` is
emitted before the whole expression, not before the `await` keyword.
Fix#14411
changelog: [`implicit_return`]: fix proposed `return` position in the
presence of asynchronous code
Instead of looking for angle brackets in the source code, use the HIR
and Ty interfaces to either copy the original type, or complete it with
`_` placeholders if all type and const generic arguments are inferred.
`Option<Symbol>` is a much nicer and idiomatic way of representing "no
name" using empty symbols. And it works naturally for the item ordering
checking because `None < Some(_)` just like the empty string compares
less than all non-empty strings.
changelog: none
There were two bugs here. Let's assume `T` is a singleton type
implementing `Default` and that `f()` takes a `T`:
- `f(<T>::default())` cannot be replaced by `f(<T)` as it was (incorrect
spans – this is tricky because the type relative path uses a base span
covering only `T`, not `<T>`) (third commit)
- The argument of `f(<_>::default())` is inferred correctly, but cannot
be replaced by `<_>` or `_`, as this cannot be used to infer an instance
of a singleton type (first commit).
The second commit offers better error messages by pointing at the whole
expression.
Fix#12654
changelog: [`default_constructed_unit_struct`]: do not suggest incorrect
fix when using a type surrounded by brackets
`non_canonical_partial_ord_impl` will now recognize two forms of
canonical implementations: `Some(self.cmp(other))` and
`self.cmp(other).into()`.
changelog: [`non_canonical_partial_ord_impl`]: recognize
`self.cmp(other).into()` as a canonical implementation of
`PartialOrd::partial_cmp()`.
Fixesrust-lang/rust-clippy#13640
Fixes rust-lang/rust-clippy#14449, introduced in #14314
changelog: [`map_entry`]: fix a false positive where the lint would
trigger without any insert calls present
changelog: [`manual_abs_diff`]: Initial implementation
Hey, first time writing a new lint for clippy, hope I got it right. I
think it's pretty self-explanatory!
Added a few `fixme` test cases, where the lint can be improved to catch
more (probably rare) patterns, but opening a PR with this initial
implementation to make sure I'm on the right track, and that this lint
is acceptable at all.
😁
We do not want to remove casts done inside macros. Also, when printing
the suggestion, take it from the same context as the origin expression
(the root context).
Problems found while working on #14526, but should be merged even if
#14526 is not.
changelog: none
`assert_eq!()` and `assert_ne!()` are not expanded the same way as
`assert!()` (they use a `match` instead of a `if`). This makes them
being recognized as well.
This PR fixes issues with the `missing_asserts_for_indexing` lint.
- false positive when the first index is the highest(or equal) value in
a list of indexes:
```rust
pub fn foo(slice: &[i32]) -> i32{
slice[1] * slice[0]
}
```
- false negative when an assert statement if found after the indexing
operation.
```rust
pub fn bar(slice: &[i32]) -> i32 {
let product = slice[0] * slice[1];
assert!(slice.len() > 1);
product
}
```
examples: https://godbolt.org/z/s7Y47vKdEcloses: #14079
changelog: [`missing_asserts_for_indexing`]: ignore asserts found after
indexing, and do not require asserts if the first index is highest.
