…hanges.

Return with a question mark was triggered in situations where the `?`
desuraging was performing error conversion via `Into`/`From`.

The desugared `?` produces a match over an expression with type
`std::ops::ControlFlow<B,C>` with `B:Result<Infallible, E:Error>` and
`C:Result<_, E':Error>`, and the arms perform the conversion. The patch
adds another check in the lint that checks that `E == E'`. If `E == E'`,
then the `?` is indeed unnecessary.

changelog: False Positive: `needless_return_with_question_mark` when
implicit Error Conversion occurs.

… lint emit warning

There are cases where the closure call is needed in some macros, this in
particular occurs when the closure has parameters. To handle this case,
we allow the lint when there are no parameters in the closure, or the
closure is outside a macro invocation.

fixes: rust-lang#11274, rust-lang#1553
changelog: FP: [`redundant_closure_call`] when closures with parameters
are passed in macros.

`unescape_literal` becomes `unescape_unicode`, and `unescape_c_string`
becomes `unescape_mixed`. Because rfc3349 will mean that C string
literals will no longer be the only mixed utf8 literals.

Add lint configuration for `modulo_arithmetic`

Collect meta-data

…ubtree-update

remove StructuralEq trait

The documentation given for the trait is outdated: *all* function pointers implement `PartialEq` and `Eq` these days. So the `StructuralEq` trait doesn't really seem to have any reason to exist any more.

One side-effect of this PR is that we allow matching on some consts that do not implement `Eq`. However, we already allowed matching on floats and consts containing floats, so this is not new, it is just allowed in more cases now. IMO it makes no sense at all to allow float matching but also sometimes require an `Eq` instance. If we want to require `Eq` we should adjust rust-lang#115893 to check for `Eq`, and rule out float matching for good.

Fixes rust-lang#115881

Avoid linting redundant closure when callee is marked `#[track_caller]`

Fixes rust-lang#12199

Not sure if there's a nicer way to detect functions marked `#[track_caller]` other than by just looking at its attributes 🤔

changelog: [`redundant_closure`]: [`redundant_closure_for_method_calls`]: avoid linting closures where the function being called is marked `#[track_caller]`

Co-authored-by: y21 <30553356+y21@users.noreply.github.com>

…lyxyas

Warn if an item coming from more recent version than MSRV is used

Part of rust-lang/rust-clippy#6324.

~~Currently, the lint is not working for the simple reason that the `stable` attribute is not kept in dependencies. I'll send a PR to rustc to see if they'd be okay with keeping it.~~

EDIT: There was actually a `lookup_stability` function providing this information, so all good now!

cc `@epage`

changelog: create new [`incompatible_msrv`] lint

…1-dead

RFC 3349 precursors

Some cleanups I found while working on RFC 3349 that are worth landing separately.

r? `@fee1-dead`

…Manishearth

Clippy subtree update

r? `@Manishearth`

Closes rust-lang/rust-clippy#12148

Fixed FP in `redundant_closure_call` when closures are passed to macros

There are cases where the closure call is needed in some macros, this in particular occurs when the closure has parameters. To handle this case, we allow the lint when there are no parameters in the closure, or the closure is outside a macro invocation.

fixes: rust-lang#11274 rust-lang#1553
changelog: FP: [`redundant_closure_call`] when closures with parameters are passed in macros.

…ero, r=llogiq

Don't warn about modulo arithmetic when comparing to zero

closes rust-lang#12006

By default, don't warn about modulo arithmetic when comparing to zero. This behavior is configurable via `clippy.toml`.

See discussion [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/.E2.9C.94.20Is.20issue.20.2312006.20worth.20implementing.3F)

changelog: [`modulo_arithmetic`]: By default don't lint when comparing the result of a modulo operation to zero.

add to_string_trait_impl lint

closes rust-lang#12076

changelog: [`to_string_trait_impl`]: add lint for direct `ToString` implementations

…_or_else, r=llogiq

Add new `unnecessary_result_map_or_else` lint

Fixes rust-lang/rust-clippy#7328.

r? `@llogiq`

changelog: Add new `unnecessary_result_map_or_else` lint

[`never_loop`]: recognize desugared `try` blocks

Fixes rust-lang#12205

The old code assumed that only blocks with an explicit label can be jumped to (using `break`). This is mostly correct except for `try` desugaring, where the `?` operator is rewritten to a `break` to that block, even without a label on the block. `Block::targeted_by_break` is a little more accurate than just checking if a block has a label in that regard, so we should just use that instead

changelog: [`never_loop`]: avoid linting when `?` is used inside of a try block

Fix/Issue11932: assert* in multi-condition after unrolling will cause lint `nonminimal_bool` emit warning

fixes [Issue#11932](rust-lang/rust-clippy#11932)

After `assert`, `assert_eq`, `assert_ne`, etc, assert family marcos unrolling in multi-condition expressions, lint `nonminimal_bool` will recognize whole expression as a entirety, analyze each simple condition expr of them, and check whether can simplify them.

But `assert` itself is a entirety to programmers, we don't need to lint on `assert`. This commit add check whether lint snippet contains `assert` when try to warning to an expression.

changelog: [`nonminimal_bool`] add check for condition expression

fix: incorrect suggestions generated by `manual_retain` lint

fixes rust-lang#10393, fixes rust-lang#11457, fixes rust-lang#12081

rust-lang#10393: In the current implementation of `manual_retain`, if the argument to the closure is matched using tuple, they are all treated as the result of a call to `map.into_iter().filter(<f>)`. However, such tuple pattern matching can also occur in many different containers that stores tuples internally. The correct approach is to apply different lint policies depending on whether the receiver of `into_iter` is a map or not.

rust-lang#11457 and rust-lang#12081: In the current implementation of `manual_retain`, if the argument to the closure is `Binding`, the closure will be used directly in the `retain` method, which will result in incorrect suggestion because the first argument to the `retain` closure may be of a different type. In addition, if the argument to the closure is `Ref + Binding`, the lint will simply remove the `Ref` part and use the `Binding` part as the argument to the new closure, which will lead to bad suggestion for the same reason. The correct approach is to detect each of these cases and apply lint suggestions conservatively.

changelog: [`manual_retain`] refactor and add check for various patterns

FP: `needless_return_with_question_mark` with implicit Error Conversion

Return with a question mark was triggered in situations where the `?` desuraging was performing error conversion via `Into`/`From`.

The desugared `?` produces a match over an expression with type `std::ops::ControlFlow<B,C>` with `B:Result<Infallible, E:Error>` and `C:Result<_, E':Error>`, and the arms perform the conversion. The patch adds another check in the lint that checks that `E == E'`. If `E == E'`, then the `?` is indeed unnecessary.

changelog: False Positive: [`needless_return_with_question_mark`] when implicit Error Conversion occurs.

fixes: rust-lang#11982

Fixes rust-lang#10854.

Co-authored-by: Alejandra González <blyxyas@gmail.com>

…t-closure-for-method-calls, r=blyxyas

[fix] [`redundant_closure_for_method_calls`] Suggest relative paths for local modules

Fixes rust-lang#10854.

Currently, `redundant_closure_for_method_calls` suggest incorrect paths when a method defined on a struct within inline mod is referenced (see the description in the aforementioned issue for an example; also see [this playground link](https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=f7d3c5b2663c9bd3ab7abdb0bd38ee43) for the current-version output for the test cases added in this PR). It will now try to construct a relative path path to the module and suggest it instead.

changelog: [`redundant_closure_for_method_calls`] Fix incorrect path suggestions for types within local modules

Fixes rust-lang/rust-clippy#12201

…pt-param-file, r=flip1995

Makes clippy-driver check for --sysroot in arg files

Fixes rust-lang/rust-clippy#12201

---

changelog: none

cc: `@UebelAndre` `@illicitonion`

…71, r=blyxyas

Add regression ui test for rust-lang#2371

Fixes rust-lang#2371.

rust-lang#2371 seems to already be handled correctly in the lint. This PR adds a ui regression test so we can close it.

r? `@blyxyas`

changelog: Add regression ui test for rust-lang#2371

…or segments

The query accept arbitrary DefIds, not just owner DefIds.
The return can be an `Option` because if there are no nodes, then it doesn't matter whether it's due to NonOwner or Phantom.
Also rename the query to `opt_hir_owner_nodes`.

Remove various `has_errors` or `err_count` uses

follow up to rust-lang#119895

r? `@nnethercote` since you recently did something similar.

There are so many more of these, but I wanted to get a PR out instead of growing the commit list indefinitely. The commits all work on their own and can be reviewed commit by commit.

`Diagnostic::keys`, which is used for hashing and equating diagnostics,
has a surprising behaviour: it ignores children, but only for lints.
This was added in rust-lang#88493 to fix some duplicated diagnostics, but it
doesn't seem necessary any more.

This commit removes the special case and only four tests have changed
output, with additional errors. And those additional errors aren't
exact duplicates, they're just similar. For example, in
src/tools/clippy/tests/ui/same_name_method.rs we currently have this
error:
```
error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:79:9
   |
LL |         impl T1 for S {}
   |         ^^^^^^^^^^^^^^^^
```
and with this change we also get this error:
```
error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:81:9
   |
LL |         impl T2 for S {}
   |         ^^^^^^^^^^^^^^^^
```
I think printing this second argument is reasonable, possibly even
preferable to hiding it. And the other cases are similar.

hir: Refactor getters for owner nodes

…estebank

Don't hash lints differently to non-lints.

`Diagnostic::keys`, which is used for hashing and equating diagnostics, has a surprising behaviour: it ignores children, but only for lints. This was added in rust-lang#88493 to fix some duplicated diagnostics, but it doesn't seem necessary any more.

This commit removes the special case and only four tests have changed output, with additional errors. And those additional errors aren't exact duplicates, they're just similar. For example, in src/tools/clippy/tests/ui/same_name_method.rs we currently have this error:
```
error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:79:9
   |
LL |         impl T1 for S {}
   |         ^^^^^^^^^^^^^^^^
```
and with this change we also get this error:
```
error: method's name is the same as an existing method in a trait
  --> $DIR/same_name_method.rs:75:13
   |
LL |             fn foo() {}
   |             ^^^^^^^^^^^
   |
note: existing `foo` defined here
  --> $DIR/same_name_method.rs:81:9
   |
LL |         impl T2 for S {}
   |
```
I think printing this second argument is reasonable, possibly even preferable to hiding it. And the other cases are similar.

r? `@estebank`

Warns when a lint group in Cargo.toml's `[lints]` section shares the
same priority as a lint

…p1995

Add `lint_groups_priority` lint

Warns when a lint group in Cargo.toml's `[lints]` section shares the same priority as a lint. This is in the cargo section but is categorised as `correctness` so it's on by default, it doesn't call `cargo metadata` though and parses the `Cargo.toml` directly

The lint should be temporary until rust-lang/cargo#12918 is resolved, but in the meanwhile this is an common issue to run into

- rust-lang#11237
- rust-lang#11751
- rust-lang#11830

changelog: Add [`lint_groups_priority`] lint

r? `@flip1995`

We introduce the following rules for match exprs.
- `panic!` and `unreachable!` are treated as consumption.
- guard expressions in any arm imply consumption.

For match exprs:
- Lint only if exacrtly 2 non-consuming arms exist
- Lint only if one arm is an `Ok(_)` and the other is `Err(_)`

Added additional requirement that for a block return expression
that is a match, the source must be `Normal`.

changelog: FP [`unused_io_amount`] when matching Ok(literal)

Fixed FP in `unused_io_amount` for Ok(lit), unrachable! and unwrap de…

…sugar

Fixes fp caused by linting on Ok(_) for all cases outside binding.

We introduce the following rules for match exprs.
- `panic!` and `unreachable!` are treated as consumed.
- `Ok( )` patterns outside `DotDot` and `Wild` are treated as consuming.

changelog: FP [`unused_io_amount`] when matching Ok(literal) or unreachable

fixes rust-lang#12208

r? `@blyxyas`

add configuration for [`wildcard_imports`] to ignore certain imports

fixes: rust-lang#11428

changelog: add configuration `ignored-wildcard-imports` for lint [`wildcard_imports`]

Avoid deleting labeled blocks

Fix rust-lang#11575.

changelog: [`unnecessary_operation`]: skip labeled blocks

Author:    Marcin Serwin <marcin.serwin0@protonmail.com>

Add new lint: `ref_as_ptr`

Fixes rust-lang#10130

Added new lint `ref_as_ptr` that checks for conversions from references to pointers and suggests using `std::ptr::from_{ref, mut}` instead.

The name is different than suggested in the issue (`as_ptr_cast`) since there were some other lints with similar names (`ptr_as_ptr`, `borrow_as_ptr`) and I wanted to follow the convention.

Note that this lint conflicts with the `borrow_as_ptr` lint in the sense that it recommends changing `&foo as *const _` to `std::ptr::from_ref(&foo)` instead of `std::ptr::addr_of!(foo)`. Personally, I think the former is more readable and, in contrast to `addr_of` macro, can be also applied to temporaries (cf. rust-lang#9884).

---

changelog: New lint: [`ref_as_ptr`]
[rust-lang#12087](rust-lang/rust-clippy#12087)

Changelog for Clippy 1.76 🐈

Roses are red,
Violets are blue,
So many cute cats,
How to choose?

---

### The cat of this release is: *Cabrel* submitted by `@daniel-g-gagnon:`

<img height=500 src="https://github.com/rust-lang/rust-clippy/assets/17087237/41aea3dc-7935-4dfe-80ff-a6efd92f76ab" alt="The cats of this Clippy release" />

The cat for the next release can be voted on: [here](https://docs.google.com/forms/d/e/1FAIpQLSfERam31AEi3_5uVsugi1-JHGF9Po1oC7OIiLs8jglprZNy_g/viewform)

The cat for the next next release can be nominated in the comments and will be voted in the next changelog PR (Submission deadline is 2024-02-06 23:59CET)

---

changelog: none

make matching on NaN a hard error, and remove the rest of illegal_floating_point_literal_pattern

These arms would never be hit anyway, so the pattern makes little sense. We have had a future-compat lint against float matches in general for a *long* time, so I hope we can get away with immediately making this a hard error.

This is part of implementing rust-lang/rfcs#3535.

Closes rust-lang#41620 by removing the lint.

rust-lang/reference#1456 updates the reference to match.

new lint: `manual_c_str_literals`

With rust-lang#117472 merged and `c""` syntax stabilized, I think it'd be nice to have a lint for using `CStr::from_ptr` (and similar constructors) with a string literal as an argument.
We can probably also lint `"foo\0".as_ptr()` and suggest `c"foo".as_ptr()`. I might add that to this PR tomorrow if I find the time.

The byte string literal to c string literal rewriting is ugly but oh well.

changelog: new lint: `manual_c_str_literals`
[rust-lang#11919](rust-lang/rust-clippy#11919)

[`redundant_locals`]: take by-value closure captures into account

Fixes rust-lang#12225

The same problem in the linked issue can happen to regular closures too, and conveniently async blocks are closures in the HIR so fixing closures will fix async blocks as well.

changelog: [`redundant_locals`]: avoid linting when redefined variable is captured by-value

Fix release year in CHANGELOG.md

Fixes a typo in rust-lang#12224

CC: `@xFrednet` `@Manishearth`

---

changelog: none

Return `Some` from `walk_to_expr_usage` more

fixes rust-lang#11786
supersedes rust-lang#11097

The code removed in the first commit would have needed changes due to the second commit. Since it's useless it just gets removed instead.

changelog: `needless_borrow`: Fix linting in tuple and array expressions.

…s-fix, r=Jarcho

Fix false positive in `redundant_type_annotations` lint

This PR changes the `redundant_type_annotations` lint to allow slice type annotations (i.e., `&[u8]`) for byte string literals. It will still consider _array_ type annotations (i.e., `&[u8; 4]`) as redundant. The reasoning behind this is that the type of byte string literals is by default a reference to an array, but, by using a type annotation, you can force it to be a slice. For example:
```rust
let a: &[u8; 4] = b"test";
let b: &[u8] = b"test";
```

Now, the type annotation for `a` will still be linted (as it is still redundant), but the type annotation for `b` will not.

Fixes rust-lang#12212.

changelog: [`redundant_type_annotations`]: Fix false positive with byte string literals

[`unconditional_recursion`]: compare by `Ty`s instead of `DefId`s

Fixes rust-lang#12154
Fixes rust-lang#12181 (this was later edited in, so the rest of the description refers to the first linked issue)

Before this change, the lint would work with `DefId`s and use those to compare types. This PR changes it to compare types directly. It fixes the linked issue, but also other false positives I found in a lintcheck run. For example, one of the issues is that some types don't have `DefId`s (primitives, references, etc., leading to possible FNs), and the helper function used to extract a `DefId` didn't handle type parameters.

Another issue was that the lint would use `.peel_refs()` in a few places where that could lead to false positives (one such FP was in the `http` crate). See the doc comment on one of the added functions and also the test case for what I mean.

The code in the linked issue was linted because the receiver type is `T` (a `ty::Param`), which was not handled in `get_ty_def_id` and returned `None`, so this wouldn't actually *get* to comparing `self_arg != ty_id` here, and skip the early-return:
https://github.com/rust-lang/rust-clippy/blob/70573af31eb9b8431c2e7923325c82ba0304cbb2/clippy_lints/src/unconditional_recursion.rs#L171-L178

This alone could be fixed by doing something like `&& get_ty_def_id(ty).map_or(true, |ty_id)| self_arg != ty_id)`, but we don't really need to work with `DefId`s in the first place, I don't think.

changelog: [`unconditional_recursion`]: avoid linting when the other comparison type is a type parameter

Rustup

r? `@ghost`

changelog: none