Fixes#12551
changelog: [`empty_enum_variants_with_brackets`]: Do not lint reachable
enums or enums which are used as functions within the same crate.
r? @xFrednet
The `BodyLifetimeChecker` which checks for the use of any non-anonymous
non-static lifetime did not recurse into closures, missing lifetime
uses. This would lead to a bogus elision suggestion.
The `BodyLifetimeChecker` is not refined enough to avoid false
positives, as any conforming lifetime, including one coming from the
outer context, would be considered a hit. The number of false positives
might increase now that we check closures as well, in case those
closures define and use lifetimes themselves.
changelog: [`needless_lifetimes`]: do not suggest removing a lifetime
which is later used in a closure
Fixesrust-lang/rust-clippy#14607
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
To accurately reflect that RPITIT assoc items don't have a name. This
avoids the use of `kw::Empty` to mean "no name", which is error prone.
Helps with #137978.
The `BodyLifetimeChecker` which checks for the use of any non-anonymous
non-static lifetime did not recurse into closures, missing lifetime
uses. This would lead to a bogus elision suggestion.
The `BodyLifetimeChecker` is not refined enough to avoid false
positives, as any conforming lifetime, including one coming from the outer
context, would be considered a hit. The number of false positives might
increase now that we check closures as well, in case those closures
define and use lifetimes themselves.
`hir::AssocItem` currently has a boolean `fn_has_self_parameter` field,
which is misplaced, because it's only relevant for associated fns, not
for associated consts or types. This commit moves it (and renames it) to
the `AssocKind::Fn` variant, where it belongs.
This requires introducing a new C-style enum, `AssocTag`, which is like
`AssocKind` but without the fields. This is because `AssocKind` values
are passed to various functions like `find_by_ident_and_kind` to
indicate what kind of associated item should be searched for, and having
to specify `has_self` isn't relevant there.
New methods:
- Predicates `AssocItem::is_fn` and `AssocItem::is_method`.
- `AssocItem::as_tag` which converts `AssocItem::kind` to `AssocTag`.
Removed `find_by_name_and_kinds`, which is unused.
`AssocItem::descr` can now distinguish between methods and associated
functions, which slightly improves some error messages.
`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
Allow drivers to supply a list of extra symbols to intern
Allows adding new symbols as `const`s in external drivers, desirable in Clippy so we can use them in patterns to replace code like 75530e9f72/src/tools/clippy/clippy_lints/src/casts/cast_ptr_alignment.rs (L66)
The Clippy change adds a couple symbols as a demo, the exact `clippy_utils` API and replacing other usages can be done on the Clippy side to minimise sync conflicts
---
try-job: aarch64-gnu
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.
