add suggestions to rc_clone_in_vec_init
A followup to https://github.com/rust-lang/rust-clippy/pull/8769
I also switch the order of the 2 suggestions, since the loop initialization one is probably the common case.
`@xFrednet` I'm not letting you guys rest for a minute 😅
changelog: add suggestions to [`rc_clone_in_vec_init`]
Fix ICE in `let_unit_value` when calling a static or const callable type
fixes#8821
changelog: Fix ICE in `let_unit_value` when calling a static or const callable type
`undocumented_unsafe_blocks` does not trigger on unsafe trait impls
Closes#8505
changelog: This lint checks unsafe impls NOT from macro expansions and checks ones in macro declarations.
~~`unsafe impl`s from macro invocations don't trigger the lint for now.~~
~~This lint checks unsafe impls from/not from macro expansions~~
Don't lint `vec_init_then_push` when further extended
fixes#7071
This will still lint when a larger number of pushes are done (four currently). The exact number could be debated, but this is more readable then a sequence of pushes so it shouldn't be too large.
changelog: Don't lint `vec_init_then_push` when further extended.
changelog: Remove `mut` binding from `vec_init_then_push` when possible.
Rename `eval_order_dependence` to `mixed_read_write_expression`, move to nursery
As per the [reference](https://doc.rust-lang.org/1.51.0/reference/expressions.html#evaluation-order-of-operands) evaluation order is now defined.
I'm pretty sure rust always compiled with this evaluation order anyways so there's no reason the put an msrv limit on the lint.
changelog: Rename `eval_order_dependence` to `mixed_read_write_expression`, move to nursery
Add `duplicate_mod` lint
Inspired by #8827, warns if there's a single file that is loaded by more than one `mod` item
```rust,ignore
// lib.rs
mod a;
mod b;
```
```rust,ignore
// a.rs
#[path = "./b.rs"]
mod b;
```
It adds a `canonicalize` call per `mod file;` encountered, which I don't think should be too heavy
Integration tests with common modules, e.g. [`test_utils`](2038084cf2/tests/test_utils) doesn't trigger it as each test is compiled separately, however I couldn't figure out a good way to add a test for that
changelog: Add [`duplicate_mod`] lint
Fix redundant_allocation warning for Rc<Box<str>>
changelog: [`redundant_allocation`] Fixes#8604
Fixes false positives where a fat pointer with `str` type was made thin by another allocation, but that thinning allocation was marked as redundant
Tweak some words improved representation
Hello! Thank you for this awesome project!
This PR has implemented improved representation.
- Use "lib" instead of "lifb"
- Use "triggered" instead of "triggere"
- Use "blacklisted_name" instead of "blackisted_name"
- Use "stabilization" instead of "stabilisation"
- Use "behavior" instead of "behaviour"
- Use "target" instead of "tartet"
- Use "checked_add" instead of "chcked_add"
- Use "anti-pattern" instead of "antipattern"
- Use "suggestion" instead of "suggesttion"
- Use "example" instead of "exampel"
- Use "Cheat Sheet" instead of "Cheatsheet"
---
changelog: none
This PR has implemented improved representation.
- Use "lib" instead of "lifb"
- Use "triggered" instead of "triggere"
- Use "blacklisted_name" instead of "blackisted_name"
- Use "stabilization" instead of "stabilisation"
- Use "behavior" instead of "behaviour"
- Use "target" instead of "tartet"
- Use "checked_add" instead of "chcked_add"
- Use "anti-pattern" instead of "antipattern"
- Use "suggestion" instead of "suggesttion"
- Use "example" instead of "exampel"
- Use "Cheat Sheet" instead of "Cheatsheet"
Some lintcheck cleanup
A grab bag of smaller changes:
Panics if a crate source isn't valid, and fixes the `ryu` crate entry so it's picked up. Took me a while to realise why I couldn't do `cargo lintcheck --only ryu` 😅
Parses messages with `cargo_metadata`, this catches a few more lints that were ignored because the message had an [expansion field](https://docs.rs/cargo_metadata/latest/cargo_metadata/diagnostic/struct.DiagnosticSpanMacroExpansion.html) that contained a path pointing into `.../.toolchains/...`. It also no longer emits some log lines with `null` as the column
It also merges the `run_clippy_lint` invocations and splits `LintcheckConfig` out into its own file
changelog: none
New lint: [`derive_partial_eq_without_eq`]
Introduces a new lint, [`derive_partial_eq_without_eq`].
See: #1781 (doesn't close it though).
changelog: add lint [`derive_partial_eq_without_eq`]
Replace `#[allow]` with `#[expect]` in Clippy
Hey `@rust-lang/clippy,` `@Alexendoo,` `@dswij,` I'm currently working on the expect attribute as defined in [Rust RFC 2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). With that, an `#[allow]` attribute can be replaced with a `#[expect]` attribute that suppresses the lint, but also emits a warning, if the lint isn't emitted in the expected scope.
With this PR I would like to test the attribute on a project scale and Clippy obviously came to mind. This PR replaces (almost) all `#[allow]` attributes in `clippy_utils` and `clippy_lints` with the `#[expect]` attribute. I was also able to remove some allows since, the related FPs have been fixed 🎉.
My question is now, are there any concerns regarding this? It's still okay to add normal `#[allow]` attributes, I see the need to nit-pick about that in new PRs, unless it's actually a FP. Also, I would not recommend using `#[expect]` in tests, as changes to a lint could the trigger the expect attribute in other files.
Additionally, I've noticed that Clippy has a bunch of `#[allow(clippy::too_many_lines)]` attributes. Should we maybe allow the lint all together or increase the threshold setting? To me, it seems like we mostly just ignore it in our code. 😅🙃
---
changelog: none
r? `@flip1995` (I've requested you for now, since you're also helping with reviewing the expect implementation. You are welcome to delegate this PR, even if it should be a simple review 🙃 )
Recommend let chains over if_chain in docs
Switches over bit_mask.rs to let chains in order to create a nice example
While the rustfmt thing isn't resolved yet, my rust-analyzer isn't a fan of large `if_chains!`s, it stops giving me hover info and such after some number of if statements
changelog: none
