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.

Only lint when `into_iter` is an implementation of `IntoIterator`
Minor cleanups

Fix `macro_use_import` ICE

fixes: rust-lang#7015
changelog: Fix `macro_use_import` ICE

…ffen

Invalid null usage v2

This is continuation of rust-lang#6192 after inactivity.

I plan to move paths into the compiler as diagnostic items after this is merged.

fixes rust-lang#1703
changelog: none

This still applies the lint, and also adds a structured suggestion to
rename it.

Use `register_renamed` instead of `register_removed` for uplifted lints

This still applies the lint, and also adds a structured suggestion to
rename it.

changelog: Use `register_renamed` instead of `register_removed` for lints uplifted to rustc

…fn, r=flip1995

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: rust-lang/rust-clippy#6082

r? `@flip1995`

changelog: Change `panic_in_result_fn` to ignore `debug_assert` and co macros

…arth

Fix false-positive `debug_assert` in `panic`

This fixes a false-positive in `clippy::panic` when `debug_assert` is used with a message.

Fixes rust-lang/rust-clippy#7062.

changelog: Fix false-positive in `panic` when `debug_assert` is used with a message

…0, r=giraffate

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 rust-lang#5210

changelog: none

Deprecate `filter_map`

Since rust-lang#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 rust-lang#3424
Fixes rust-lang#7050

…ishearth

Add a note on the issue rust-lang#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 rust-lang#5953 to the known problems section.

Introduce `is_lang_ctor`

changelog: none

Replaces `is_some_ctor` and `is_ok_ctor`. Removes many path usages.

…lip1995

Fix `explicit_into_iter_loop`

fixes: rust-lang#6900

changelog: Only lint when `into_iter` is an implementation of `IntoIterator`

Fix FP in `wrong_self_convention` lint

Previously, this lint didn't check into impl block when it was implementing a trait.
Recent improvements (rust-lang#6924) have moved this check and some impl blocks are now checked but they shouldn't, such as in rust-lang#7032.

Fixes rust-lang#7032

changelog: Fix FP when not taking `self` in impl block for `wrong_self_convention` lint

…-return, r=llogiq

Fix a false negative on `needless return`

closes rust-lang#7042

changelog: fix a false negative on `needless return`

Remove paths::STD_PTR_NULL

Related to rust-lang#5393

changelog: none

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).

where a function that calls a standard library function whose constness
is unstable is considered as being able to be a const function

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 rust-lang#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

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 rust-lang#5835

changelog: Fix ICE in `tabs_in_doc_comments`

Fix changelog check output

Error messages are more helpful if you can see them.

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

Lint `if _.[!]contains_key(&_) { .. } else { .. }` so long as one of the branches contains an insertion.

Suggest using `or_insert_with` when possible

…hearth

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

… except the `author` lint.

Add note to fix `MATCH_TYPE_ON_DIAG_ITEM`
Add false negative test for `uninit_assumed_init`

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 when the drop order change may result in different behaviour.

… trait # Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Fri Apr 2 19:04:45 2021 -0400
#
# On branch redundant_pattern_matching
# Your branch is ahead of 'origin/redundant_pattern_matching' by 1 commit.
# (use "git push" to publish your local commits)
#
# Changes to be committed:
#	modified: clippy_lints/src/matches.rs
# # Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Fri Apr 2 19:04:45 2021 -0400
#
# interactive rebase in progress; onto ebc64690d
# Last commands done (6 commands done):
# pick 25d211ad8 Code cleanup and additional std types checked
# r 0c71ce56f `redundant_pattern_matching` fix inverted boolean when missing `Drop` trait
# No commands remaining.
# You are currently editing a commit while rebasing branch 'redundant_pattern_matching' on 'ebc64690d'.
#
# Changes to be committed:
#	modified: clippy_lints/src/matches.rs
#

Check for `PartialEq` in addition to `StructuralPartialEq` before suggesting `==`

Don't allow adjustments for `manual_map`

fixes: rust-lang#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

Fix `single_match`

fixes: rust-lang#7038
changelog: Don't suggest an equality check for types which don't implement `PartialEq` in `single_match`

Improve `map_entry` suggestion

fixes: rust-lang#5176
fixes: rust-lang#4674
fixes: rust-lang#4664
fixes: rust-lang#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.

…lip1995

Fix: redundant_pattern_matching drop order

Fixes rust-lang#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

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 rust-lang#3870

…, r=camsteffen,flip1995

Fixing FPs for the `branches_sharing_code` lint

Fixes rust-lang#7053
Fixes rust-lang#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 🙃

Allow allman style braces in `suspicious_else_formatting`

fixes: rust-lang#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`

add type in help message of from_over_into

fixes rust-lang#7088
changelog: add type in help message of from_over_into

Per discussion in rust-lang/rust-clippy#6372, this lint has significant false positives.

…deny]`/`#[forbid]` attributes

Do not ignore path segments in the middle in `#[allow]`/`#[warn]`/`#[deny]`/`#[forbid]` attributes

Fixes rust-lang#83477.

Add `Unsupported` to `std::io::ErrorKind`

I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations.
The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just "an unspecified error occurred", which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`.

**Implementation**:

The following variant will be added to `std::io::ErrorKind`:

```rust
/// This operation is unsupported on this platform.
Unsupported
```
`std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform, and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate, e.g. on wasm for file and network operations.

`decode_error_kind` will be updated  to decode operating system errors to `Unsupported`:
- Unix and VxWorks: `libc::ENOSYS`
- Windows: `c::ERROR_CALL_NOT_IMPLEMENTED`
- WASI: `wasi::ERRNO_NOSYS`

**Stability**:
This changes the kind of error returned by some functions on some platforms, which I think is not covered by the stability guarantees of the std? User code could depend on this behavior, expecting `ErrorKind::Other`, however the docs already mention:

> Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics, e.g., a specific `Error::raw_os_error` return value.

The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago), but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it, so adding a new variant per se should not be a breaking change.

The variant `Unsupported` itself could be marked as `#[unstable]`, however, because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.

…earth

un-double `return` on try_err

This fixes rust-lang#7103 by looking at the parent expression and omitting the "return " in the suggestion when its already a `return` expression.

---

changelog: none

Add flat_map_option lint

changelog: Add flat_map_option lint

Closes rust-lang#2241

…, r=camsteffen

Update pull request template

A follow-up of <rust-lang/rust-clippy#7064 (comment)>.

changelog: none

…ng#7091

Fix links in doc

changelog: none

useless use of format! should return function directly

fixes rust-lang#7066

changelog: [`useless_format`] wraps the content in the braces when it's needed.

r? `@giraffate`