useless use of format! should return function directly
fixes#7066
changelog: [`useless_format`] wraps the content in the braces when it's needed.
r? `@giraffate`
Allow allman style braces in `suspicious_else_formatting`
fixes: #3864
Indentation checks could be added as well, but the lint already doesn't check for it.
changelog: Allow allman style braces in `suspicious_else_formatting`
Fixing FPs for the `branches_sharing_code` lint
Fixes#7053Fixes#7054
And an additional CSS adjustment to support dark mode for every inline code. It currently only works in paragraphs, which was an oversight on my part 😅. [Current Example](https://rust-lang.github.io/rust-clippy/master/index.html#blacklisted_name)
This also includes ~50 lines of doc comments and is therefor not as big as the changes would indicate. 🐧
---
changelog: none
All of these bugs were introduced in this dev version and are therefor not worth a change log entry.
r? `@phansch`
cc: `@camsteffen` since you have a pretty good overview of the `SpanlessEq` implementation 🙃
Add `cloned_instead_of_copied` lint
Don't go cloning all willy-nilly.
Featuring a new `get_iterator_item_ty` util!
changelog: Add cloned_instead_of_copied lint
Closes#3870
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
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
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
