Closes https://github.com/rust-lang/rust-clippy/issues/10118
This lint checks `map_or` method calls to check if they can be
consolidated down to something simpler and/or more readable.
For example, the code
```rs
let x = Some(5);
x.map_or(false, |n| n == 5)
```
can be rewritten as
```rs
let x = Some(5);
x == Some(5)
```
In addition, when the closure is more complex, the code can be altered
from, say,
```rs
let x = Ok::<Vec<i32>, i32>(vec![5]);
x.map_or(false, |n| n == [5])
```
into
```rs
let x = Ok::<Vec<i32>, i32>(vec![5]);
x.is_some_and(|n| n == [5])
```
This lint also considers cases where the `map_or` can be chained with
other method calls, and accommodates accordingly by adding extra
parentheses as needed to the suggestion.
changelog: add new lint `unnecessary_map_or`
Fixes#13670.
Bug was that I forgot to add the comparison with the included file
content length...
changelog: Fix `large_include_file` lint being triggered all the time by
doc comments
The `identity_op` lint was suggesting code fixes that resulted in
incorrect or broken code, due to missing parenthesis in the fix that
changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in rustfix generating broken code and failing, or
generating code that has different behavior than before the fix. e.g.
`-(x + y + 0)` would turn into `-x + y`, changing the behavior, and
`1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would turn
into `1u64 + x + y as u64`, creating an error where `x` cannot be added
to the other values, as it was never cast to `u64`.
This commit fixes both of these problems by always checking the
non-redundant child of a binary expression for needed parenthesis.
fixes#13470
changelog: [`identity_op`]: Fix suggested code that is broken or has
changed behavior
Now that lints can add @eval_always at the end of their definition, the lint
declaration might not end right after the description. The `update_lints`
command can skip everything that comes after that.
The author lint is not an internal lint, and should also be enabled, when Clippy
is distributed through rustup. This moves the author lint test cases back to
tests/ui.
Do not filter empty lint passes & re-do CTFE pass
Some structs implement `LintPass` without having a `Lint` associated with them #125116 broke that behaviour by filtering them out. This PR ensures that lintless passes are not filtered out.
Swap Visitors to early exit, instead of storing poison flag
I noticed that a bunch of visitors had a `poison` or `success` field, when they could just be returning `ControlFlow`.
changelog: none
Remove unnecessary pub enum glob-imports from `rustc_middle::ty`
We used to have an idiom in the compiler where we'd prefix or suffix all the variants of an enum, for example `BoundRegionKind`, with something like `Br`, and then *glob-import* that enum variant directly.
`@noratrieb` brought this up, and I think that it's easier to read when we just use the normal style `EnumName::Variant`.
This PR is a bit large, but it's just naming.
The only somewhat opinionated change that this PR does is rename `BorrowKind::Imm` to `BorrowKind::Immutable` and same for the other variants. I think these enums are used sparingly enough that the extra length is fine.
r? `@noratrieb` or reassign
needless_continue: check labels consistency before warning
changelog: [`needless_continue`]: check labels before warning about `continue` as the last statement in a loop body
Fix#13641
no_mangle attribute requires unsafe in Rust 2024
Tests without unsafe must not run in edition 2024. Also, error messages have been modified to include the full attribute, so that a use of `#[unsafe(no_mangle)]` does not produce an error message containing `#[no_mangle]`.
changelog: [`no_mangle_attribute`]: handle `#[unsafe(no_mangle)]` as well
Return iterator must not capture lifetimes in Rust 2024
In Rust 2024, by default lifetimes will be captured which does not reflect the reality since we return an iterator of `DefId` which do not capture the input parameters.
changelog: none
Don't lint unnamed consts and nested items within functions in `missing_docs_in_private_items`
With this change we no longer require doc comments for `const _: ()` items as well as nested items in functions or other bodies. In both of those cases, rustdoc generates no documentation even with `--document-private-items`.
Fixes#13427 (first commit)
Fixes#13298 (second commit)
cc https://github.com/rust-lang/rust-clippy/issues/5736#issuecomment-668524296
changelog: [`missing_docs_in_private_items`]: avoid linting in more cases where rustdoc generates no documentation
The `identity_op` lint was suggesting code fixes that resulted
in incorrect or broken code, due to missing parenthesis in the fix
that changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in either rustfix generating broken code and failing,
or code that has different behavior than before the fix.
e.g. `-(x + y + 0)` would turn into `-x + y`, changing the behavior,
and `1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would
turn into `1u64 + x + y as u64`, creating broken code where `x` cannot
be added to the other values, as it was never cast to `u64`.
This commit fixes both of these cases by always checking the
non-redundant child of a binary expression for needed parenthesis, and
makes it so if we need parenthesis, but they already exist, we don't add
any redundant ones.
Fixes#13470
Improve display of clippy lints page when JS is disabled
There is no point in displaying the settings menu and the filters if JS is disabled. So in this case, this PR simply hides it:
![image](https://github.com/user-attachments/assets/e96039a9-e698-49b7-bf2b-70e78442b305)
For the theme handling though, I need to send a fix to mdBook first. But once done, it'll look as expected (dark if system is in dark mode).
changelog: Improve clippy lints page display when JS is disabled.
r? `@Alexendoo`
new lint: `source_item_ordering`
changelog: [`source_item_ordering`]: Introduced a new restriction lint that checks the ordering of items in Modules, Enums, Structs, Impls and Traits.
From the written documentation:
> Why restrict this?
> Keeping a consistent ordering throughout the codebase helps with working as a team, and possibly improves maintainability of the codebase. The idea is that by defining a consistent and enforceable rule for how source files are structured, less time will be wasted during reviews on a topic that is (under most circumstances) not relevant to the logic implemented in the code. Sometimes this will be referred to as "bike-shedding".
>
> Keep in mind, that ordering source code alphabetically can lead to reduced performance in cases where the most commonly used enum variant isn't the first entry anymore, and similar optimizations that can reduce branch misses, cache locality and such. Either don't use this lint if that's relevant, or disable the lint in modules or items specifically where it matters. Other solutions can be to use profile guided optimization (PGO), or other advanced optimization methods.
I tried to build it as configurable as possible, as such a highly opinionated lint should be adjustable to personal opinions.
I'm open to any input and will be available both here and on the zulip for communication. In the meantime I'll be testing this lint against my own code-bases, which I've (manually) kept ordered with the default config, to see how well it works in practice.
And lastly, a big thanks to the community for making clippy the best linter there is!
Use match ergonomics compatible with editions 2021 and 2024
This PR contains the minimal changes needed to make Clippy match ergonomics work with both Rust 2021 and Rust 2024.
changelog: none
[`infinite_loops`]: fix incorrect suggestions on async functions/closures
closes: #12338
I intend to fix this in #12421 but got distracted by some other problems in the same lint, delaying the process of closing the actual issue. So here's a separated PR that only focus on the issue and nothing else.
---
changelog: [`infinite_loops`]: fix suggestion error on async functions/closures