* Don't lint on `.cloned().flatten()` when `T::Item` doesn't implement `IntoIterator`
* Reduce verbosity of lint message
* Narrow down the scope of the replacement range
Clippy book
A work in progress Clippy Book using mdbook. See #6011.
This is currently just a moving around of things:
1. The current README.md split up a bit and put into sections.
1. A rough outline of Clippy lint categories (currently no content, potentially add a basic introduction for each and some example, see questions below.
1. The `docs` content repurposed into a top level `Development` section.
1. The current Roadmap.
Some big questions:
1. is `guide/` the right place? I'm modeling after mdbook itself.
1. What is the relationship between ALL the Clippy Lints and this guide? It seems like they can coexist. Does that mean the guide should just point to the current side with regard to actual lints, and maybe just include some examples to keep it interesting? Keeping both up to date seems like a maintenance nightmare unless its automated somehow. Or should the current ALL the Clippy lints somehow be incorporated into the book?
1. Related to the above, where should this guide be published since the `gh-pages` branch is already in use?
1. This PR doesn't currently change any existing content. Obviously that would make sense assuming the general structure and relocation is an acceptable approach.
---
Open Tasks for follow up PR:
- Set up CI/CD
- Split up Installation and Usage
- Add more content to Usage (and Installation) chapters
- Enhance CI chapter with more examples for different CIs
---
changelog: The first version of the *Clippy Book*
staring, *The Clippy Team*, *Bors* and *rustc*
List configuration values can now be extended instead of replaced
I've seen some `clippy.toml` files, that have a few additions to the default list of a configuration and then a copy of our default. The list will therefore not be updated, when we add new names. This change should make it simple for new users to append values instead of replacing them.
I'm uncertain if the documentation of the `".."` is apparent. Any suggestions are welcome. I've also check that the lint list displays the examples correctly.
<details>
<summary>Lint list screenshots</summary>
</details>
---
changelog: enhancement: [`doc_markdown`]: Users can now indicate, that the `doc-valid-idents` should extend the default and not replace it
changelog: enhancement: [`blacklisted-name`]: Users can now indicate, that the `blacklisted-names` should extend the default and not replace it
Closes: #8877
That's it. Have a fantastic weekend to everyone reading this. Here is a cookie 🍪
- Move doc about defining remotes to the front and use the defined
remotes in the further documentation
- Don't recommend pushing to the remote repo directly
- Add some clarifying comments
This removes the empty separate files for the different groups and adds
a single file giving short explanations for each group and what to
expect from those groups.
The UI tests now use the latest edition by default. Testing on older
editions should almost never be necessary, so I don't see a need to
document this.
This reformats all the internal docs, so that the md files use at most
80 characters per line. This is the usual formatting of md files. We
allow 120 chars per line in CI though.
Add new lint [`needless_parens_on_range_literals`]
changelog: Adds a new lint [`needless_parens_on_range_literals`] to warn on needless braces on literals in a range statement
For example, the lint would catch
```log
error: needless parenthesis on range literals can be removed
--> $DIR/needless_parens_on_range_literals.rs:8:13
|
LL | let _ = ('a')..=('z');
| ^^^^^ help: try: `'a'`
|
= note: `-D clippy::needless-parens-on-range-literals` implied by `-D warnings`
```
improve [`for_loops_over_fallibles`] to detect the usage of iter, iter_mut and into_iterator
fix#6762
detects code like
```rust
for _ in option.iter() {
//..
}
```
changelog: Improve [`for_loops_over_fallibles`] to detect `for _ in option.iter() {}` or using `iter_mut()` or `into_iterator()`.
Remove the unneeded wrapping and unwrapping in suggestion creation.
Collecting to Option<Vec<_>> only returns None if one of the elements is
None and that is never the case here.
