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`.
Partially outline code inside the panic! macro
This outlines code inside the panic! macro in some cases. This is split out from https://github.com/rust-lang/rust/pull/115562 to exclude changes to rustc.
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?
Assorted improvements for `rustc_middle::mir::traversal`
r? `@cjgillot`
I'm not _entirely_ sure about all changes, although I do like all of them. If you'd like I can drop some commits. Best reviewed on a commit-by-commit basis, I think, since they are fairly isolated.
[`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
Clippy backport: Move needless_raw_string_hashes to pedantic
Really small backport this time. Context: https://github.com/rust-lang/rust-clippy/pull/11415#issuecomment-1739880932
I'd rather get this in 1.74 than waiting another release cycle.
r? `@Manishearth`
cc `@Mark-Simulacrum` This should be merged before beta is branched tomorrow.
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
Don't store lazyness in `DefKind::TyAlias`
1. Don't store lazyness of a type alias in its `DefKind`, but instead via a query.
2. This allows us to treat type aliases as lazy if `#[feature(lazy_type_alias)]` *OR* if the alias contains a TAIT, rather than having checks for both in separate parts of the codebase.
r? `@oli-obk` cc `@fmease`
subst -> instantiate
continues #110793, there are still quite a few uses of `subst` and `substitute`, but changing them all in the same PR was a bit too much, so I've stopped here for now.
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 🎉.
