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`]
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
Check expr usage for `manual_flatten`
Fixes#6784Fixes#7538
`manual_flatten` should not trigger when `if let` match expression will be used.
changelog: [`manual_flatten`] checks for expr usage after `if let`
Manual map 7413
fixes: #7413
This only fixes the specific problem from #7413, not the general case. The full fix requires interacting with the borrow checker to determine the lifetime of all the borrows made in the function. I'll open an issue about it later.
changelog: Don't suggest using `map` when the option is borrowed in the match, and also consumed in the arm.
changelog: Locals declared within the would-be closure will not prevent the closure from being suggested in `manual_map` and `map_entry`
lintcheck always copies in a fresh crate when provided with a crate path
changelog: none
When lintcheck is run on local crates it copies the crate to `target/lintcheck/sources/crate_name` on the first run only.
Then in subsequent runs of lintcheck it reuses this same copy.
This caching behaviour makes sense when dealing with immutable crates.io releases and git commits.
However it is quite surprising that the changes to my local crate are not used when I run lintcheck.
To fix this I removed the copy, instead clippy runs directly off the provided crate folder.
I have tested this and have not observed any negative effects from doing this.
But maybe i'm missing something as im not familiar with clippy!
Alternatively we could make it copy the entire crate every run, but that seems problematic to me as multi-gigabyte target folders will take a long time to copy and wear down SSDs for developers who frequently run lintcheck.
Downgrade option_if_let_else to nursery
I believe that this lint's loose understanding of ownership (#5822, #6737) makes it unsuitable to be enabled by default in its current state, even as a pedantic lint.
Additionally the lint has known problems with type inference (#6137), though I may be willing to consider this a non-blocker in isolation if it weren't for the ownership false positives.
A fourth false positive involving const fn: #7567.
But on top of these, for me the biggest issue is I basically fully agree with https://github.com/rust-lang/rust-clippy/issues/6137#issuecomment-705605688. In my experience this lint universally makes code worse even when the resulting code does compile.
---
changelog: remove [`option_if_let_else`] from default set of enabled lints
* Captures by sub closures are now considered
* Copy types are correctly borrowed by reference when their value is used
* Fields are no longer automatically borrowed by value
* Bindings in `match` and `let` patterns are now checked to determine how a local is captured
Use `avoid-breaking-exported-api` configuration in types module
This PR empowers our lovely `avoid-breaking-exported-api` configuration value to also influence the emission of lints inside the `types` module.
(That's pretty much it, not really a change worthy of writing a fairy tale about. Don't get me wrong, I would love to write a short one, but I sadly need to study now).
---
Closes: rust-lang/rust-clippy#7489
changelog: The `avoid-breaking-exported-api` configuration now also works for [`box_vec`], [`redundant_allocation`], [`rc_buffer`], [`vec_box`], [`option_option`], [`linkedlist`], [`rc_mutex`]
changelog: [`rc_mutex`]: update the lint message to comply with the normal format
---
r? `@camsteffen,` as you implemented the configuration value
cc: `@flip1995,` as we've discussed this change in rust-lang/rust-clippy#7308
Add `unwrap_or_else_default` lint
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: Add a new [`unwrap_or_else_default`] style lint. This will catch `unwrap_or_else(Default::default)` on Result and Option and suggest `unwrap_or_default()` instead.
No effect inclusive range
I noticed during last PR that range expression is `ExprKind::Struct` while inclusive range is `ExprKind::Call` which was why it was not handled. This PR adds check for this case.
changelog: [`no_effect]` Report inclusive range in no_effect lint
`never_loop`: suggest using an `if let` instead of a `for` loop
changelog: suggest using an `if let` statement instead of a `for` loop that [`never_loop`]s
Fixes#7537, r? `@camsteffen.`
