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!
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`.
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
Add units/unit prefixes of frequency to doc-valid-idents
These units/unit prefixes often come up in the embedded world.
Should this PR also modify the `test_units` test? It seems only concerned with data units currently; should it also test frequency units?
changelog: [`doc_markdown`]: Add MHz, GHz, and THz to `doc-valid-idents`.
Turn declare_clippy_lint into a declarative macro
Ease of development, and hopefully compile times (the dependencies are still there because of ui-test). The procedural macro was doing just some very basic processing (like assigning a lint level to each category), so it didn't have a reason to stay IMO
changelog: None
Reduce default 'large array' threshold
As-is this threshold is `512kb`, but as #9449 points out this is way too high for most people to consider sensible (why would you want to copy `256kb` of data around on the stack or duplicate it via `const`) and didn't get any discussion when originally added. This PR reduces it the threshold to `1kb`, which is higher than the issue says ("a few cpu words") but helps out for actual codebases.
While reducing this, I found that `large_stack_arrays` was triggering for statically promoted arrays in constants/statics, so I also fixed that up as seen in the difference to [array_size_threshold.stderr](https://github.com/rust-lang/rust-clippy/compare/master...GnomedDev:rust-clippy:reduce-large-threshold?expand=1#diff-4c2a2a855d9ff7777f1d385be0c1bede2a3fc8aaab94837cde27a35235233fc7).
Closes#9449.
changelog: [`large_stack_arrays`]: No longer triggers in `static`/`const` context
changelog: [`large_const_arrays`]: Changed the default of [`array-size-threshold`] from `512kb` to `16kb`
Simplify negative `Option::{is_some_and,is_none_or}`
Closes#13436.
Improved based on the existing lint `nonminimal_bool`, since there is already handling of similar methods `Option::{is_some,is_none}` and `Result::{is_ok,is_err}`, and there is a lot of reusable code.
When `is_some_and` or `is_none_or` have a negation, we invert it into another method by removing the Not sign and inverting the expression in the closure.
For the case where the closure block has statements, currently no simplification is implemented. (Should we do it?)
```rust
// Currently will not simplify this
_ = !opt.is_some_and(|x| {
let complex_block = 100;
x == complex_block
});
```
changelog: [`nonminimal_bool`]: Simplify negative `Option::{is_some_and,is_none_or}`
Extend `implicit_saturating_sub` lint
Fixes#10070.
It can serve as base if we want to add equivalent checks for other arithmetic operations.
Also one important note: when writing this lint, I realized that I could check for wrong conditions performed beforehand on subtraction and added another part in the lint. Considering they both rely on the same checks, I kept both in the same place. Not sure if it makes sense though...
changelog: Extend `implicit_saturating_sub` lint
Misc changes to `clippy_config`
Contains part of #13084
Changes include:
* Sort config list and each configs lint list.
* Add default text for the two configs that were missing it.
* Switch the lint list in the configs to an attribute.
* Make `dev fmt` sort the config list.
r? `@xFrednet`
changelog: none
* Construct lint passes by taking `Conf` by reference.
* Use `HashSet` configs in less places
* Move some `check_crate` code into the pass constructor when possible.
* "AccessKit" is a commonly used accessibility toolkit used in Rust GUIs.
* "CoreFoundation", "CoreGraphics", "CoreText" are frameworks on Apple OSes.
* "Direct2D", "Direct3D", "DirectWrite" are frameworks on Windows
* "PostScript" is a programming language and is mentioned when talking about
text and vector graphics.
* "OpenAL" is an audio framework / API.
* "OpenType" is a font format (TrueType is already mentioned).
* "WebRTC", "WebSocket", "WebTransport" are web networking technologies.
* "NetBSD" and "OpenBSD" are like the already included FreeBSD.
