Update Clippy #87954
Merged
Update Clippy #87954
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Philipp Krones <[email protected]> Co-authored-by: Takayuki Nakata <[email protected]>
Updated changelog for 1.55 This has again been a bit of work, but I'm happy to notice that my English is still improving, and I'm getting faster at these things. That's a very nice side effect of contributing and getting feedback on reviews 😊 Moving on, there were a few things that I was unsure about: * The PR rust-lang#86717 changes an old entry in the change log, is this worth mentioning? I've left it out for now. * The stabilization of `cargo clippy --fix` is quite awesome and important IMO. It sadly gets a bit lost in the *Other* entry, as it's the last one. Do we maybe want to move it somewhere else or change the headline order for this release? * I've listed the introduction of the new `suspicious` group under the *Moves and Deprecations* section. Is this alright, or should it be moved to the *Other* section as well? * Last but definitely not least, some fun! I've used the 🎉 emoji in the `cargo clippy --fix` entry, is this okay? Sorry for the bombardment of questions xD --- The PR already includes the entries for the new metadata collection and website updates. These are not merged yet, but should probably be to make this correct. This might also require the commit hashes to be updated (Not sure on this, though). It would actually be super fitting to get this into this release as we also stabilize `--fix`. TODOs: * [x] Merge metadata collection PRs: 1. rust-lang#7279 2. rust-lang#7298 3. rust-lang#7420 (Hope to not get any merge conflicts) --- [Rendered 📰](https://github.com/xFrednet/rust-clippy/blob/changelog-1-55/CHANGELOG.md) r? `@flip1995` changelog: none
Remove `or_patterns` feature gate in example changelog: removed `or_patterns` feature gate in the code example for the [`unnested_or_patterns`] lint
Updated config value name in change log for 1.54 Hey, I've noticed that the change log for 1.54 references the avoid_breaking_exported_api configuration with its Rust name, not the name it actually has in the config file. This should fix it for everyone, as the blog post references our change log on the master branch. Just a very small PR xD changelog: none (This is the change log xD) r? `@flip1995`
Since RFC 3052 soft deprecated the authors field anyway, hiding it from crates.io, docs.rs, and making Cargo not add it by default, and it is not generally up to date/useful information, we should remove it from crates in this repo.
* Use more accurate span for `async move` suggestion * Use more accurate span for deref suggestion * Use `multipart_suggestion` more often
…ochenkov Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by default This PR makes the `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint warn by default. To avoid showing a large number of un-actionable warnings to users, we only enable the lint for macros defined in the same crate. This ensures that users will be able to fix the warning by simply removing a semicolon. In the future, I'd like to enable this lint unconditionally, and eventually make it into a hard error in a future edition. This PR is a step towards that goal.
Use `multipart_suggestions` more Built on top of rust-lang#86532
Reborrow mutable references rather then take a reference to them.
When the iterator is one field within a local correctly check for usages of the field
Fix `while_let_on_iterator` - rust-lang#7510 fixes: rust-lang#7510 changelog: Suggest re-borrowing mutable references in `while_let_on_iterator`
Adds a check on `.map(..).flatten()` on `Result` type that follows the behaviour on `Option` type.
Workaround rust-lang/rustfmt#4477 - relative paths in `path` attribute See rust-lang/rustfmt#4477 changelog: None
rfc3052 followup: Remove authors field from Cargo manifests Since RFC 3052 soft deprecated the authors field, hiding it from crates.io, docs.rs, and making Cargo not add it by default, and it is not generally up to date/useful information for contributors, we may as well remove it from crates in this repo.
Cover `Result` on `map_flatten` lint Closes rust-lang#7496 changelog: `[map_flatten]` handles `Result` type
…, r=flip1995
Updated `define_Conf!` to support multi-line doc comments
Updated the `define_Conf!` macro to support multi-line doc comments for readability. This also enables configuration documentation to have multiple paragraphs.
I've also added the `metadata-collector-lint` feature to the CI build and testing tasks. (I would think that we want this, now that we officially switched over)
---
Now a small informal explanation what this PR changes (just for fun):
* *Once upon a time there was a monster. It was handsome, supportive and happy to dig through the best source code it has ever seen. Spanning over hundreds of lines and reading over complete crates, it was purely marvels!*
*However, there was one region in its territory that wasn't clean and well formatted like the rest. That was the mighty `define_Conf` macro. The monster would have cleaned it up a long time ago but, the previous ruler of this kingdom a powerful Python script was prohibiting it. But now that the old king was slain in the great battle of rust-1.54.0, everything was possible again. Our lovely monster was now able to grab its cleaning equipment and get some nice formatting into the now unprotected area.*
*Said and done! Let this day go down in history!*
(I'll be the first to admit, that I'm a bit lost today. And I'm also procrastinating on some other discussions where I have some catching up to do... Oh, well, this was fun)
---
changelog: none
r? `@flip1995`
…teffen `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 rust-lang#7537, r? `@camsteffen.`
…ip1995 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
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.
similar_names: allow "iter" and "item" changelog: [`similar_names`] no longer complains about `iter` and `item` being too similar
Rustup r? `@ghost` changelog: none
|
Some changes occurred in src/tools/clippy. cc @rust-lang/clippy |
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ |
|
📌 Commit f92a0c8 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Sep 3, 2021
Update Clippy r? `@Manishearth`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
r? @Manishearth