Rework `branches_sharing_code`
fixes#7378
This changes the lint from checking pairs of blocks, to checking all the blocks at the same time. As such there's almost none of the original code left.
changelog: Don't lint `branches_sharing_code` when using different binding names
Test metadata collection in Bors CI workflow
This PR adds a new check to bors CI workflows, which ensures that the metadata collection success, when it's run as part of the `deploy` script. I've only added it to bors workflows, as the runtime will be high while it'll also succeed most of the time. This is a preparation for rust-lang/rust-clippy#8947.
---
changelog: none
r? `@ghost`
Fix some `#[expect]` lint interaction
Fixing the first few lints that aren't caught by `#[expect]`. The root cause of these examples was, that the lint was emitted at the wrong location.
---
changelog: none
r? `@Jarcho`
cc: rust-lang/rust#97660
Improve lint doc consistency
changelog: none
This is a continuation of #8908.
Notable changes:
- Removed empty `Known Problems` sections
- Removed "Good"/"Bad" language (replaced with "Use instead")
- Removed (and added some 😄) duplication
- Ignored the [`create_dir`] example so it doesn't create `clippy_lints/foo` 😄
fix(lint): check const context
close: https://github.com/rust-lang/rust-clippy/issues/8898
This PR fixes a bug in checked_conversions.
Thank you in advance.
changelog: check const context in checked_conversions.
* 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.
