Fix false positive `unconditional_recursion`
Fixes#12052.
Only checking if both variables are `local` was not enough, we also need to confirm they have the same type as `Self`.
changelog: Fix false positive for `unconditional_recursion` lint
Fixes: #12050 - `identity_op` correctly suggests a deference for coerced references
When `identity_op` identifies a `no_op`, provides a suggestion, it also checks the type of the type of the variable. If the variable is a reference that's been coerced into a value, e.g.
```
let x = &0i32;
let _ = x + 0;
```
the suggestion will now use a derefence. This is done by identifying whether the variable is a reference to an integral value, and then whether it gets dereferenced.
changelog: false positive: [`identity_op`]: corrected suggestion for reference coerced to value.
fixes: #12050
New Lint: [`thread_local_initializer_can_be_made_const`]
Adds a new lint to suggest using `const` on `thread_local!` initializers that can be evaluated at compile time.
Impl details:
The lint relies on the expansion of `thread_local!`. For non const-labelled initializers, `thread_local!` produces a function called `__init` that lazily initializes the value. We check the function and decide whether the body can be const. If so, we lint that the initializer value can be made const.
changelog: new lint [`thread_local_initializer_can_be_made_const`]
fixes: #12015
Adds a new lint to suggest using `const` on `thread_local!`
initializers that can be evaluated at compile time.
Impl details:
The lint relies on the expansion of `thread_local!`. For non
const-labelled initializers, `thread_local!` produces a function
called `__init` that lazily initializes the value. We check the function
and decide whether the body can be const. The body of the function is
exactly the initializer. If so, we lint the body.
changelog: new lint [`thread_local_initializer_can_be_made_const`]
Issue 8733: Suggest `str.lines` when splitting at hard-coded newlines
Fixes#8733.
```
changelog: [`splitting_strings_at_newlines`]: New lint that suggests `str.lines` over splitting at hard-coded newlines
```
This is my first PR to Clippy and one of my first Rust PRs in general -- please feel free to nitpick, I'm thankful for any opportunity to learn! I'd be especially interested in feedback to the following points:
* Is checking for `'\n'`, `"\n"`, and `"\r\n"` as arguments to `split` enough, or should we do more (e.g. checking for constants that have those values if that is possible)?
* Could the code be written in a more idiomatic way?
* Is the default `".."` for `snippet` a good choice? I copied it from other uses of `snippet` in the code base, but I'm not entirely sure.
* Is the category `suspicious` a good choice?
* Is the suggestion applicability `MaybeIncorrect` a good choice? I used it because the return type of `lines` is not exactly the same as that of `split`.
Extend UNCONDITIONAL_RECURSION to check for ToString implementations
Follow-up of https://github.com/rust-lang/rust-clippy/pull/11938.
r? `@llogiq`
changelog: Extend `UNCONDITIONAL_RECURSION` to check for `ToString` implementations
New Lint: empty_enum_variants_with_brackets
This PR:
- adds a new early pass lint that checks for enum variants with no fields that were defined using brackets. **Category: Restriction**
- adds relevant UI tests for the new lint.
Closes#12007
```
changelog: New lint: [`empty_enum_variants_with_brackets`]
```
don't lint [`default_numeric_fallback`] on return and local assigned macro calls with type stated
fixes: #11535
changelog: don't lint [`default_numeric_fallback`] on return and local assigned macro calls with type stated
feat: add `manual_is_variant_and` lint
changelog: add a new lint [`manual_is_variant_and`].
- Replace `option.map(f).unwrap_or_default()` and `result.map(f).unwrap_or_default()` with `option.is_some_and(f)` and `result.is_ok_and(f)` where `f` is a function or closure that returns `bool`.
- MSRV is set to 1.70.0 for this lint; when `is_some_and` and `is_ok_and` was stabilised
---
For example, for the following code:
```rust
let opt = Some(0);
opt.map(|x| x > 1).unwrap_or_default();
```
It suggests to instead write:
```rust
let opt = Some(0);
opt.is_some_and(|x| x > 1)
```
make [`mutex_atomic`] more type aware
fixes: #9872
---
changelog: [`mutex_atomic`] now suggests more specific atomic types and skips mutex i128 and u128
add external macro checks to `iter_without_into_iter` and `into_iter_without_iter`
Fixes#12037
I think it's useful to still lint on local macros, since the user should still be able to add another impl with the `IntoIterator` or `iter` method. I think it's also fairly common to write a macro for generating many impls (e.g. for many similar types), so it'd be nice if we can continue linting in those cases.
For that reason I went with `in_external_macro`.
I also added a test for `#[allow]`ing the lint while I was at it.
changelog: [`iter_without_into_iter`]: don't lint if the `iter` method is defined in an external macro
changelog: [`into_iter_without_iter`]: don't lint if the `IntoIterator` impl is defined in an external macro
When `identity_op` identifies a `no_op`, provides a suggestion, it also
checks the type of the type of the variable. If the variable is
a reference that's been coerced into a value, e.g.
```
let x = &0i32;
let _ = x + 0;
```
the suggestion will now use a derefence. This is done by identifying
whether the variable is a reference to an integral value, and then
whether it gets dereferenced.
changelog: false positive: [`identity_op`]: corrected suggestion for
reference coerced to value.
fixes: #12050
feature: add new lint `pub_underscore_fields`
fixes: #10282
This PR introduces a new lint `pub_underscore_fields` that lints when a user has marked a field of a struct as public, but also prefixed it with an underscore (`_`). This is something users should avoid because the two ideas are contradictory. Prefixing a field with an `_` is inferred as the field being unused, but making a field public infers that it will be used.
- \[x] Followed [lint naming conventions][lint_naming]
- I believe I followed the naming conventions, more than happy to update the naming if I did not :)
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[x] Executed `cargo dev update_lints`
- \[x] Added lint documentation
- \[x] Run `cargo dev fmt`
---
changelog: new lint: [`pub_underscore_fields`]
[#10283](https://github.com/rust-lang/rust-clippy/pull/10283)
<!-- changelog_checked -->
- add a new late pass lint, with config options
- add ui tests for both variations of config option
- update CHANGELOG.md
github feedback
bump version to 1.77 and run cargo collect-metadata
Change `,` to `;` in `conf.rs`
Remove mitigations for incorrect node args
This change https://github.com/rust-lang/rust/pull/118420/files#r1419874371 adds a missing `write_args` to properly record node args for lang-item calls.
Thus, in the `unnecessary_to_owned` lint, this ensures that the `call_generic_args` extracted by `get_callee_generic_args_and_args` are always correct, and we can remove the mitigation for #9504 and #10021 since the root cause has been fixed.
I'm not sure if there is other now-unnecessary code that can be removed, but this is the one I found when investigating https://github.com/rust-lang/rust-clippy/issues/11965#issuecomment-1871732518.
changelog: none
6459: Check for redundant `matches!` with `Ready`, `Pending`, `V4`, `V6`
Fixes#6459.
```
changelog: [`redundant_pattern_matching`]: Add checks for `Poll::{Ready,Pending}` and `IpAddr::{V4,V6}` in `matches!`
```
new lint: `eager_transmute`
A small but still hopefully useful lint that looks for patterns such as `(x < 5).then_some(transmute(x))`.
This is almost certainly wrong because it evaluates the transmute eagerly and can lead to surprises such as the check being completely removed and always evaluating to `Some` no matter what `x` is (it is UB after all when the integer is not a valid bitpattern for the transmuted-to type). [Example](https://godbolt.org/z/xoY34fPzh).
The user most likely meant to use `then` instead.
I can't remember where I saw this but this is inspired by a real bug that happened in practice.
This could probably be a correctness lint?
changelog: new lint: [`eager_int_transmute`]
Make some non-diagnostic-affecting `QPath::LangItem` into regular `QPath`s
The rest of 'em affect diagnostics, so leave them alone... for now.
cc #115178
New lints `iter_filter_is_some` and `iter_filter_is_ok`
Adds a pair of lints that check for cases of an iterator over `Result` and `Option` followed by `filter` without being followed by `map` as that is covered already by a different, specialized lint.
Fixes#11843
PS, I also made some minor documentations fixes in a case where a double tick (`) was included.
---
changelog: New Lint: [`iter_filter_is_some`]
[#12004](https://github.com/rust-lang/rust/pull/12004)
changelog: New Lint: [`iter_filter_is_ok`]
[#12004](https://github.com/rust-lang/rust/pull/12004)
Make closures carry their own ClosureKind
Right now, we use the "`movability`" field of `hir::Closure` to distinguish a closure and a coroutine. This is paired together with the `CoroutineKind`, which is located not in the `hir::Closure`, but the `hir::Body`. This is strange and redundant.
This PR introduces `ClosureKind` with two variants -- `Closure` and `Coroutine`, which is put into `hir::Closure`. The `CoroutineKind` is thus removed from `hir::Body`, and `Option<Movability>` no longer needs to be a stand-in for "is this a closure or a coroutine".
r? eholk
