Avoid slice indexing in Clippy (down with the ICEs)
While working on #7569 I got about 23 lint reports where we can avoid slice indexing by destructing the slice early. This is a preparation PR to avoid fixing them in the lint PR. (The implementation already takes about 300 lines without tests 😅). Either way, this should hopefully be easy to review 🙃
---
changelog: none
Updating issue templates again for rustbot
It turns out that our current issue template can sometimes trigger a rustbot error message, as can be seen in [#7626](https://github.com/rust-lang/rust-clippy/issues/7626). I originally tested this in #7599, but it's apparently a bit inconsistent. This PR adds backticks to the commands, as correctly suggested by `@mikerite` in the comments. (Thank you!)
``@rustbot` label +S-blocked`
---
Now I also pushed a tiny link fix as well. 🙃
---
changelog: none
Extend unnecessary_unwrap to look for expect in addition to unwrap
changelog: Extend ``[`unnecessary_unwrap`]`` to also check for `Option::expect` and `Result::expect`. Also give code suggestions in some cases.
Fixes#7581
Reference new diagnostic item docs in our docs :)
The title says it all. The rustc dev guide now has some information about diagnostic items that are worthwhile linking to 🙃
---
changelog: none
Issue 7548 fix
Close#7548
changelog: [`bool_assert_comparison`] fixes should be emitted only in case they are comparing a value of a type that implements the `Not` trait with an output of type `bool` against a boolean literal.
Fix `option_if_let_else`
fixes: #5822fixes: #6737fixes: #7567
The inference from #6137 still exists so I'm not sure if this should be moved from the nursery. Before doing that though I'd almost want to see this split into two lints. One suggesting `map_or` and the other suggesting `map_or_else`.
`map_or_else` tends to have longer expressions for both branches so it doesn't end up much shorter than a match expression in practice. It also seems most people find it harder to read. `map_or` at least has the terseness benefit of being on one line most of the time, especially when the `None` branch is just a literal or path expression.
changelog: `break` and `continue` statments local to the would-be closure are allowed in `option_if_let_else`
changelog: don't lint in const contexts in `option_if_let_else`
changelog: don't lint when yield expressions are used in `option_if_let_else`
changelog: don't lint when the captures made by the would-be closure conflict with the other branch in `option_if_let_else`
changelog: don't lint when a field of a local is used when the type could be pontentially moved from in `option_if_let_else`
changelog: in some cases, don't lint when scrutinee expression conflicts with the captures of the would-be closure in `option_if_let_else`
Updated issue templates(formatting and rustbot label reference)
This PR updates our issue templates. The changes are:
1. **Make the *Meta* section smaller and not indented**
The current format sometimes gets messed up when a user simply pasts the rustc version into the issue without indenting it to match the code block. Removing the indention should hopefully help with formatting in the future.
<details><summary>Example of messed up formatting </summary>
</details>
Additionally, I've removed the Version of Clippy from the template. Every issue that I have seen had matching rustc and Clippy versions, and just asking for `rustc -Vv` makes the issue look cleaner IMO.
2. **Add a comment explaining how additional labels can be added with ``@rustbot` label +<label>`. The explanation looks like this:**
```
<!--
Additional labels can be added to this issue by including the following command:
`@rustbot` label +<label>
Common labels for this issue type are:
* `I-suggestion-causes-error`
-->
```
The example ``@rustbot`` call can sadly not be marked as code inside a comment block. But the example will not cause the bot to add any labels. See rust-lang/rust-clippy#7599
---
changelog: none
cc: `@rust-lang/clippy`
