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.
Until now, the lint only emitted a warning, when breaking public API. Now it
doesn't lint at all when the config value is not set to `false`, bringing it in
line with the other lints using this config value.
Also ensures that this config value is documented in the lint.
Add configuration option for ignoring `panic!()` in tests
```
changelog: [`panic`]: Now can be disabled in tests with the `allow-panic-in-tests` option
```
I often find myself using `panic!(…)` in tests a lot, where I often do something like:
```rust
match enam {
Enam::A => …,
Enam::B => …,
_ => panic!("This should not happen at all."),
}
```
I think this patch should go nicely with already existing `allow-unwrap-in-tests` and `allow-expect-in-tests`.
make sure the msrv for `const_raw_ptr_deref` is met when linting [`missing_const_for_fn`]
fixes: #8864
---
changelog: make sure the msrv for `const_ptr_deref` is met when linting [`missing_const_for_fn`]
