Don't lint `manual_non_exhaustive` when enum is `#[non_exhaustive]`
Fixes#11583
changelog: Fix [`manual_non_exhaustive`] false positive for unit enum variants when enum is explicitly `non_exhaustive`.
There are cases where users create a unit variant for the purposes
of tracking the number of variants for an nonexhaustive enum.
We should check if an enum is explicitly marked as nonexhaustive
before reporting `manual_non_exhaustive` in these cases. Fixes#11583
new lint: `into_iter_without_iter`
Closes#9736 (part 2)
This implements the other lint that my earlier PR missed: given an `IntoIterator for &Type` impl, check that there exists an inherent `fn iter(&self)` method.
changelog: new lint: `into_iter_without_iter`
r? `@Jarcho` since you reviewed #11527 I figured it makes sense for you to review this as well?
[`manual_let_else`]: only omit block if span is from same ctxt
Fixes#11579.
The lint already had logic for omitting a block in `else` if a block is already present, however this didn't handle the case where the block is from a different expansion/syntax context. E.g.
```rs
macro_rules! panic_in_block {
() => { { panic!() } }
}
let _ = match Some(1) {
Some(v) => v,
_ => panic_in_block!()
};
```
It would see this in its expanded form as `_ => { panic!() }` and think it doesn't have to include a block in its suggestion because it is already there, however that's not true if it's from a different expansion like in this case.
changelog: [`manual_let_else`]: only omit block in suggestion if the block is from the same expansion
new lint: `iter_without_into_iter`
Closes#9736
A new lint that looks for `iter` (and `iter_mut`) method implementations without the type implementing `IntoIterator` for `&Type`.
Imo this seems rather pedantic, so I went with that, but I can be convinced to change it to `style` like the linked issue asked for.
Writing a machine applicable suggestion seems a bit tricky and tedious, so for now this relies on the user adding remaining lifetimes.
changelog: new lint: `iter_without_into_iter`
mir_to_const improvements
This simplifies some code and also fixes the float array handling to properly take into account the `offset`, and to work with little-endian targets.
Fixes https://github.com/rust-lang/rust-clippy/issues/11488
changelog: none
Mention that `missing_assert_message` lint ignores test functions
Updates `missing_assert_message`'s docs to reflect that it ignores test functions as pointed out by `@mickvangelderen` in https://github.com/rust-lang/rust-clippy/pull/10362#issuecomment-1732288652
---
changelog: [`missing_assert_message`]: Update docs to reflect this lint ignores test functions
Do not lint when imported item contains underscore
fix https://github.com/rust-lang/rust-clippy/issues/9942
changelog: [`wildcard_imports`]: No longer lints when imported items contain an item with the name `_`
Test that each config value exists in a test clippy.toml
Inspired by #11560, adds a test that each config option exists in some form in a `clippy.toml` in `tests/` (currently some are in `ui-toml`, some in `ui-cargo`)
changelog: none
Add colored help to be consistent with Cargo
On rust-lang/cargo#12578, a new colored help message format was introduced. This PR introduces the same styling from that `cargo help` message to our `cargo clippy --help` message.
More information is provided in the original PR, fixes#11482. The perfect reviewing process would be that the reviewer installs this branch and checks for themselves, but here are some screenshots, there are some more screenshots in the original issue.
(Note that the actual text may change in the actual commit, that screenshot is just to test the colors).
Also note that the `color-print` version **should always** be synced with Cargo's `color-print` version to avoid increasing build times in the rust-lang/rust repo.
changelog:Add colors to the `cargo clippy --help` output 🎉.
prevent ice when threshold is 0 and enum has no variants
changelog: [`enum_variant_names`]: prevent ice when threshold is 0 and enum has no variants
r? `@y21`
Fixes the same ice issue raised during review of https://github.com/rust-lang/rust-clippy/pull/11496
Add missing tests for configuration options
I noticed that a lot of lints didn't have test(s) for their configuration. This leads to issues like #11481 where the lint just does nothing with it.
This PR adds tests for *almost*[^1] all of the lints with a configuration that didn't have a test in ui-toml.
The tests that I wrote here are usually two cases: one for where it's right above or under the limit set by the config where it shouldn't lint and another one for right above where it should.
changelog: none
[^1]: allow-one-hash-in-raw-strings is ignored by needless_raw_string_hashes
