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:
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
Explain why clippy's HIR const eval exists
When I initially found this, I was wondering why clippy wasn't just using miri, but after some discussion with some rustc folks let's document why.
changelog: none
Cleanup code suggestion for `into_iter_without_iter`
Reorder the suggested code for the `IntoIterator` to match the ordering of the trait declaration:
```rust
impl IntoIterator for ... {
type Item = ...;
type IntoIter = ...;
```
changelog: none
Extend `large_include_file` lint to also work on attributes
I realized randomly while working on another lint that `large_include_file` was not emitted on attributes. This PR fixes that.
changelog: Extend `large_include_file` lint to also work on attributes
Add 'CoAP' to doc-valid-idents
CoAP is a name of a network protocol common in embedded systems; one would talk in documentation about "a CoAP server" or "a CoAP client" without referring to a specific type.
This PR fixes false positives that arise from that use.
changelog: [`doc_markdown`]: Add CoAP to `doc-valid-idents`.
As this review is identical in structure to https://github.com/rust-lang/rust-clippy/pull/13460, I'm asking for a the same reviewer (if that works):
r? `@Centri3`
Reorder the suggested code for the `IntoIterator` to match the ordering of the trait declaration:
```rust
impl IntoIterator for ... {
type Item = ...;
type IntoIter = ...;
```
Fix allow_attributes when expanded from some macros
fixes#13349
The issue here was that the start pattern being matched on the original source code was not specific enough. When using derive macros or in the issue case a `#[repr(C)]` the `#` would match the start pattern meaning that the expanded macro appeared to be unchanged and clippy would lint it.
The change I made was to make the matching more specific by matching `#[ident` at the start. We still need the second string to match just the ident on its own because of things like `#[cfg_attr(panic = "unwind", allow(unused))]`.
I also noticed some typos with start and end, these code paths weren't being reached so this doesn't fix anything.
changelog: FP: [`allow_attributes`]: don't trigger when expanded from some macros
Add new `trivial_map_over_range` lint
This lint checks for code that looks like
```rust
let something : Vec<_> = (0..100).map(|_| {
1 + 2 + 3
}).collect();
```
which is more clear as
```rust
let something : Vec<_> = std::iter::repeat_with(|| {
1 + 2 + 3
}).take(100).collect();
```
That is, a map over a range which does nothing with the parameter passed to it is simply a function (or closure) being called `n` times and could be more semantically expressed using `take`.
- [x] Followed [lint naming conventions][lint_naming]
- [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: [`trivial_map_over_range`] `restriction`
This lint checks for code that looks like
```rust
let something : Vec<_> = (0..100).map(|_| {
1 + 2 + 3
}).collect();
```
which is more clear as
```rust
let something : Vec<_> = std::iter::repeat_with(|| {
1 + 2 + 3
}).take(100).collect();
```
or
```rust
let something : Vec<_> =
std::iter::repeat_n(1 + 2 + 3, 100)
.collect();
```
That is, a map over a range which does nothing with the parameter
passed to it is simply a function (or closure) being called `n`
times and could be more semantically expressed using `take`.
New lint `map_all_any_identity`
This lint has been inspired by code encountered in Clippy itself (see the first commit).
changelog: [`map_all_any_identity`]: new lint
fix incorrect suggestion for `!(a >= b) as i32 == c`
fixes#12761
The expression `!(a >= b) as i32 == c` got simplified to `a < b as i32 == c`, but this is a syntax error.
The result we want is `(a < b) as i32 == c`.
This is fixed by adding a parenthesis to the suggestion given in `check_simplify_not` when the boolean expression is casted.
changelog: [`nonminimal_bool`]: fix incorrect suggestion for `!(a >= b) as i32 == c`
Optimise Msrv for common one item case
Currently, `Msrv` is cloned around a lot in order to handle the `#[clippy::msrv]` attribute. This attribute, however, means `RustcVersion` will be heap allocated if there is only one source of an msrv (eg: `rust-version` in `Cargo.toml`).
This PR optimizes for said case, while keeping the external interface the same by swapping the internal representation to `SmallVec<[RustcVersion; 2]>`.
changelog: none
Add test case for `missing_errors_doc` at tests with option `check-private-item=true`
Add test case for `missing_errors_doc` at tests with option `check-private-item=true` to proof that rust-lang/rust-clippy#13391 is not an issue anymore
changelog: none
Closes: rust-lang/rust-clippy#13391
Fix indentation of website code snippets
Fixes#13568
Follow up to #13359, I didn't catch that it swapped the `strip_prefix` out for a `trim` but they aren't interchangeable here
changelog: none
docs: Fix too_long_first_doc_paragraph: line -> paragraph
The documentation for too_long_first_doc_paragraph incorrectly says "line" where it should say "paragraph".
Fix a minor typo: doscstring -> docstring.
Also do a few tiny edits to attempt to make the wording slightly shorter and clearer.
changelog: [`too_long_first_doc_paragraph`]: Edit documentation
