- 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
I'm removing empty identifiers everywhere, because in practice they
always mean "no identifier" rather than "empty identifier". (An empty
identifier is impossible.) It's better to use `Option` to mean "no
identifier" because you then can't forget about the "no identifier"
possibility.
Some specifics:
- When testing an attribute for a single name, the commit uses the
`has_name` method.
- When testing an attribute for multiple names, the commit uses the new
`has_any_name` method.
- When using `match` on an attribute, the match arms now have `Some` on
them.
In the tests, we now avoid printing empty identifiers by not printing
the identifier in the `error:` line at all, instead letting the carets
point out the problem.
- 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
It's a much better name, more consistent with how we name such things.
Also rename `Lifetime::res` as `Lifetime::kind` to match. I suspect this
field used to have the type `LifetimeRes` and then the type was changed
but the field name remained the same.
The `ui_test` crate still uses 2021 as the default edition for running
rustc-like tests. This creates an unwelcome discrepancy between
`cargo dev lint` which uses Rust 2024 by default, and running UI tests
through `compile-test`.
There is a specific test that `unsafe fn` are not lint, and that
`unsafe` blocks are not lint either. Since in edition 2024 `unsafe`
blocks are required inside `unsafe fn` to do unsafe things, set up a
specific test for edition 2021.
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.
By default, edition 2024 will capture all types and lifetimes present in
the function signature when using RPIT, while edition 2021 will capture
only the lifetimes present in the RPIT itself. Adding explicit `use<>`
markers will disable the edition-specific automatic rules when they
differ.
`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
changelog: [cognitive_complexity]: Changed Test for this issue from
making sure its not a false positive to making sure its not a false
negative which was the original issue at hand. The test as it was would
also not fail without the change introduced. This test will show if any
regression is made in further pushes.
adds tests to https://github.com/rust-lang/rust-clippy/issues/14422
It's either unneeded (`warn`/`deny`) or can be replaced by individual
lints (`allow`). Also removes some redundant `allow`s covered by the
default `-Aunused` that I saw along the way
changelog: none
`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
This prevents forgotten `dbg!()` calls from entering Clippy codebase by
mistake.
Suggested by @y21 when one of my PR forgot to remove one `dbg!()` call.
changelog: none
