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>
![image](https://user-images.githubusercontent.com/17087237/130811809-2b9bc58e-c13f-4338-b34e-18648a5de413.png)
</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`
Set applicability of needless_collect to MaybeIncorrect
Fixesrust-lang/rust#88333
changelog: Set applicability of [`needless_collect`] to MaybeIncorrect
Common tool documentation uses `match_trait_method` which is deprecated.
Additionally, adds information on why `is_trait_method` is not the
preferred way.
Add module_style lint to style
changelog: Add new [`module_style`] style lint
This is a configurable (no mod file/mod file) lint that determines if `mod.rs` is used consistently or if `mod.rs` is never used (using the new mod layout).
Don't report function calls as unnecessary operation if used in array index
Attempts to fix: #7412
changelog: Don't report function calls used in indexing as unnecessary operation. [`unnecessary_operation`]
Add tests for disallowed_mod in ui-cargo test section
Use correct algorithm to determine if mod.rs is missing
Move to two lints and remove config option
Switch lint names so they read "warn on ..."
Emit the same help info for self_named_mod_file warnings
Bail when both lints are Allow
Reword help message for both module_style lints
Get piece unchecked in `write`
We already use specialized `zip`, but it seems like we can do a little better by not checking `pieces` length at all.
`Arguments` constructors are now unsafe. So the `format_args!` expansion now includes an `unsafe` block.
<details>
<summary>Local Bench Diff</summary>
```text
name before ns/iter after ns/iter diff ns/iter diff % speedup
fmt::write_str_macro1 22,967 19,718 -3,249 -14.15% x 1.16
fmt::write_str_macro2 35,527 32,654 -2,873 -8.09% x 1.09
fmt::write_str_macro_debug 571,953 575,973 4,020 0.70% x 0.99
fmt::write_str_ref 9,579 9,459 -120 -1.25% x 1.01
fmt::write_str_value 9,573 9,572 -1 -0.01% x 1.00
fmt::write_u128_max 176 173 -3 -1.70% x 1.02
fmt::write_u128_min 138 134 -4 -2.90% x 1.03
fmt::write_u64_max 139 136 -3 -2.16% x 1.02
fmt::write_u64_min 129 135 6 4.65% x 0.96
fmt::write_vec_macro1 24,401 22,273 -2,128 -8.72% x 1.10
fmt::write_vec_macro2 37,096 35,602 -1,494 -4.03% x 1.04
fmt::write_vec_macro_debug 588,291 589,575 1,284 0.22% x 1.00
fmt::write_vec_ref 9,568 9,732 164 1.71% x 0.98
fmt::write_vec_value 9,516 9,625 109 1.15% x 0.99
```
</details>
Add new lint `negative_feature_names` and `redundant_feature_names`
Add new lint [`negative_feature_names`] to detect feature names with prefixes `no-` or `not-` and new lint [`redundant_feature_names`] to detect feature names with prefixes `use-`, `with-` or suffix `-support`
changelog: Add new lint [`negative_feature_names`] and [`redundant_feature_names`]
Fix clippy::collapsible_match with let expressions
This fixes rust-lang/rust-clippy#7575 which is a regression from #80357. I am fixing the bug here instead of in the clippy repo (if that's okay) because a) the regression has not been synced yet and b) I would like to land the fix on nightly asap.
The fix is basically to re-generalize `match` and `if let` for the lint implementation (they were split because `if let` no longer desugars to `match` in the HIR).
Also fixesrust-lang/rust-clippy#7586 and fixesrust-lang/rust-clippy#7591
cc `@rust-lang/clippy`
`@xFrednet` do you want to review this?
New lint `manual_split_once`
This is a WIP because it still needs to recognize more patterns. Currently handles:
```rust
s.splitn(2, ' ').next();
s.splitn(2, ' ').nth(0)
s.splitn(2, ' ').nth(1);
s.splitn(2, ' ').skip(0).next();
s.splitn(2, ' ').skip(1).next();
s.splitn(2, ' ').next_tuple(); // from itertools
// as well as `unwrap()` and `?` forms
```
Still to do:
```rust
let mut iter = s.splitn(2, ' ');
(iter.next().unwrap(), iter.next()?)
let mut iter = s.splitn(2, ' ');
let key = iter.next().unwrap();
let value = iter.next()?;
```
Suggestions on other patterns to check for would be useful. I've done a search on github for uses of `splitn`. Still have yet to actually look through the results.
There's also the question of whether the lint shouold trigger on all uses of `splitn` with two values, or only on recognized usages. The former could have false positives where it couldn't be replaced, but I'm not sure how common that would be.
changelog: Add lint `manual_split_once`
Small documentation update for the new metadata_collector
Just small documentation updates after the merge of the new metadata collection. I'm also here to deliver on the promised fairy tale:
*Once upon a time, there was a world with many languages. One of the oldest was C a very versatile language that gave great power for the cost of great complexity and manual work. C was so powerful that it was able to create new languages. There is Java a versatile language often used by companies and in formal settings. Python that focused on readability and rapid prototyping capabilities. JavaScript which has some interesting edge cases but was still loved and widely used in the world. Together they build the foundation of our world and continue to shape the interactions between kingdoms worldwide.*
*C ruled as the king of Linux and other operating systems alongside the Queen C++. Together they were powerful leaders, in fact so powerful that they have been ruling this world for over 49 years. They remain happy together and loved by the community. However, with great power comes great responsibility! The two of them have a dark secret. To tell the truth, they sometimes suffer from memory loss and even worse in some instances from race conditions.*
*A mystical creature called Firefox lead to the creation of Mozilla, a global organization fighting for privacy and for their market share in the browser marked. As part of this fight, they started to modify parts of Firefox and eventually created Servo. A completely new creature with a new language called Rust. This new form of communication was focussed on correctness, speed and a new model of memory management.*
*Rust grew up over several years with modification to syntax, content among other things. Finally, in 2015 Rust has reached adulthood which enabled it to take part in the global discourse and shape the future of our world. Some even say that this was the start of a new area withing language design.*
*Rust had already started to build its kingdom and was now the head of a complete organization, with teams being in charge of individual tools used for further development. One team focussing on further improving Rust when it comes to complexity, style and performance was **The Clippy Team**. Its members were a friendly bunch, with mages and wizards among them.*
*With the goal of giving more power to Rust, they identified a Python tool inside Clippy that could be rewritten. This led to the creating of the **Metadata collection monster**. This monster soon replaced the old Python tool and allowed for new creative additions inside Clippy's lint list. With the eradication of the old tool, there came a possibility to update the configuration documentation to span over a lager area. This was done, but some doc comments remained until now in memory of the old tool. This is now the PR that removes these doc comments.*
---
I have to stop now, this already took way longer than the actual changes. It probably also contains some spelling mistakes, but oh well. I hope you get the gist of it 🙃.
---
r? `@camsteffen`
changelog: none
* `break` and `continue` statments local to the would-be closure are allowed
* don't lint in const contexts
* don't lint when yield expressions are used
* don't lint when the captures made by the would-be closure conflict with the other branch
* don't lint when a field of a local is used when the type could be pontentially moved from
* in some cases, don't lint when scrutinee expression conflicts with the captures of the would-be closure