Fix: redundant_pattern_matching drop order
Fixes#5746
A note about the change in drop order is added when the scrutinee (or any temporary in the expression) isn't known to be safe to drop in any order (i.e. doesn't implement the `Drop` trait, or contain such a type). There is a whitelist for some `std` types, but it's incomplete. Currently just `Vec<_>`, `Box<_>`, `Rc<_>` and `Arc<_>`, but only if the contained type is also safe to drop in any order.
Another lint for when the drop order changes could be added as allowed by default, but the drop order requirement is pretty subtle in this case. I think the note added to the lint should be enough to make someone think before applying the change.
changelog: Added a note to `redundant_pattern_matching` when the change in drop order might matter
Improve `map_entry` suggestion
fixes: #5176fixes: #4674fixes: #4664fixes: #1450
Still need to handle the value returned by `insert` correctly.
changelog: Improve `map_entry` suggestion. Will now suggest `or_insert`, `insert_with` or `match _.entry(_)` as appopriate.
changelog: Fix `map_entry` false positives where the entry api can't be used. e.g. when the map is used for multiple things.
Don't allow adjustments for `manual_map`
fixes: #7077
The other option here would be to add the return type to the closure. It would be fine for simple types, but longer types can be rather unwieldy. Could also implement the adjustment manually.
changelog: Don't lint `manual_map` when type adjustments are added. e.g. autoderef
Remove `match_path` and `match_qpath`
The only remaining usage is the `author` lint, so the functions are left in for now. The test result for `repl_uninit` changed, the lint was broken before.
The `collapsible_span_lint_calls` and `match_type_on_diag_item` tests have been changed. Both lints were broken when utils was extracted into it's own crate. `match_type_on_diag_item` isn't quite fixed, but it's at least less broken.
changelog: None
Add a note for pre-expansion passes
changelog: none
Just had to turn away a PR for using pre-expansion. I don't think that was the first time. So hopefully this will inform people sooner.
r? flip1995
Fix false positives where the map is used before inserting into the map.
Fix false positives where two insertions happen.
Suggest using `if let Entry::Vacant(e) = _.entry(_)` when `or_insert` might be a semantic change
tabs_in_doc_comments: Fix ICE due to char indexing
This is a quick-fix for an ICE in `tabs_in_doc_comments`. The problem
was that we we're indexing into possibly multi-byte characters, such as '位'.
More specifically `get_chunks_of_tabs` was returning indices into
multi-byte characters. Those were passed on to a `Span` creation that
then caused the ICE.
This fix makes sure that we don't return indices that point inside a
multi-byte character. *However*, we are still iterating over unicode
codepoints, not grapheme clusters. So a seemingly single character like y̆ ,
which actually consists of two codepoints, will probably still cause
incorrect spans in the output. But I don't think we handle those cases
anywhere in Clippy currently?
Fixes#5835
changelog: Fix ICE in `tabs_in_doc_comments`
Fix a FP in `missing_const_for_fn`
where a function that calls a standard library function whose constness
is unstable is considered as being able to be a const function. Fixes#5995.
The core change is the move from `rustc_mir::const_eval::is_min_const_fn` to `rustc_mir::const_eval::is_const_fn`. I'm not clear about the difference in their purpose between them so I'm not sure if it's acceptable to call `qualify_min_const_fn::is_min_const_fn` this way now.
---
changelog: `missing_const_for_fn`: No longer lints when an unstably const function is called
Split `is_diagnostic_assoc_item`
changelog: none
* Split `is_diagnostic_assoc_item` into `is_diag_item_method` and `is_diag_trait_item`
* `is_diag_item_method` is a bit more nuanced with the `tcx.type_of(impl_id).ty_adt_def()` step, so it seems better to keep that separate.
* No need to generalize over traits and Adt's since we know which one we want at compile time
* "item" vs. "method" because a trait may have associated items.
* Replaces the usage of the `sym::slice` diagnostic item with the `slice_alloc` lang item. The diagnostic item should be removed from rustc because it is on the `slice_alloc` impl, not slice itself (and it's not needed).
Fix FP in `wrong_self_convention` lint
Previously, this lint didn't check into impl block when it was implementing a trait.
Recent improvements (#6924) have moved this check and some impl blocks are now checked but they shouldn't, such as in #7032.
Fixes#7032
changelog: Fix FP when not taking `self` in impl block for `wrong_self_convention` lint
Add a note on the issue #5953
Hello,
I thought it would be better to have a note and warning about this issue considering it introduced an UB in the past even with the "Search on Github" feature.
---
changelog: Add a note on the issue #5953 to the known problems section.
Deprecate `filter_map`
Since #6591, `filter_map` does not even lint `filter().map()`. The cases that are still linted make no sense IMO. So this just removes/deprecates it.
changelog: Deprecate `filter_map` lint
Closes#3424Fixes#7050
Fix FP in `single_component_path_imports` lint
Fix FP in `single_component_path_imports` lint when the import is reused with `self`, like in `use self::module`.
Fixes#5210
changelog: none
Fix false-positive `debug_assert` in `panic`
This fixes a false-positive in `clippy::panic` when `debug_assert` is used with a message.
Fixes https://github.com/rust-lang/rust-clippy/issues/7062.
changelog: Fix false-positive in `panic` when `debug_assert` is used with a message
Remove `debug_assert` from `panic_in_result_fn`
I couldn't find any documentation on `debug_assert` that should be remove.
In my humble opinion, I would also like to argue that `todo` and `unreachable` shouldn't trigger this lint?
Related: https://github.com/rust-lang/rust-clippy/issues/6082
r? `@flip1995`
changelog: Change `panic_in_result_fn` to ignore `debug_assert` and co macros
