Clippyup #92849
Merged
Clippyup #92849
Conversation
This file contains 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
…elid,xFrednet Update pulldown-cmark version to 0.9 Fixes rust-lang#92206. r? `@camelid`
Clippy helpfully warns about code like this, telling you that you
probably meant "write_all":
fn say_hi<W:Write>(w: &mut W) {
w.write(b"hello").unwrap();
}
This patch attempts to extend the lint so it also covers this
case:
async fn say_hi<W:AsyncWrite>(w: &mut W) {
w.write(b"hello").await.unwrap();
}
(I've run into this second case several times in my own programming,
and so have my coworkers, so unless we're especially accident-prone
in this area, it's probably worth addressing?)
This patch covers the Async{Read,Write}Ext traits in futures-rs,
and in tokio, since both are quite widely used.
changelog: [`unused_io_amount`] now supports AsyncReadExt and AsyncWriteExt.
This improves the quality of the genrated output and makes it more in line with other lint messages. changelog: [`unused_io_amount`]: Improve help text
…Frednet
Extend unused_io_amount to cover async io.
Clippy helpfully warns about code like this, telling you that you
probably meant "write_all":
fn say_hi<W:Write>(w: &mut W) {
w.write(b"hello").unwrap();
}
This patch attempts to extend the lint so it also covers this
case:
async fn say_hi<W:AsyncWrite>(w: &mut W) {
w.write(b"hello").await.unwrap();
}
(I've run into this second case several times in my own programming,
and so have my coworkers, so unless we're especially accident-prone
in this area, it's probably worth addressing?)
Since this is my first attempt at a clippy patch, I've probably
made all kinds of mistakes: please help me fix them? I'd like
to learn more here.
Open questions I have:
* Should this be a separate lint from unused_io_amount? Maybe
unused_async_io_amount? If so, how should I structure their
shared code?
* Should this cover tokio's AsyncWrite too?
* Is it okay to write lints for stuff that isn't part of
the standard library? I see that "regex" also has lints,
and I figure that "futures" is probably okay too, since it's
an official rust-lang repository.
* What other tests are needed?
* How should I improve the code?
Thanks for your time!
---
changelog: [`unused_io_amount`] now supports async read and write traits
…earth fix [`redundant_closure`] fp with `Rc<F>`/`Arc<F>` fixes rust-lang#8073 changelog: don't trigger [`redundant_closure`] on `Arc<F>` or `Rc<F>`
The `wrong_self_convention` lint uses a `SelfKind` type to decide
whether a method has the right kind of "self" for its name, or whether
the kind of "self" it has makes its name confusable for a method in
a common trait. One possibility is `SelfKind::No`, which is supposed
to mean "No `self`".
Previously, SelfKind::No matched everything _except_ Self, including
references to Self. This patch changes it to match Self, &Self, &mut
Self, Box<Self>, and so on.
For example, this kind of method was allowed before:
```
impl S {
// Should trigger the lint, because
// "methods called `is_*` usually take `self` by reference or no `self`"
fn is_foo(&mut self) -> bool { todo!() }
}
```
But since SelfKind::No matched "&mut self", no lint was triggered
(see rust-lang#8142).
With this patch, the code above now gives a lint as expected.
Fixes rust-lang#8142
changelog: [`wrong_self_convention`] rejects `self` references in more cases
Remove existing problematic cases.
Inspired by a discussion in rust-lang/rust-clippy#8197 --- r? `@llogiq` changelog: none The lint is this on nightly, therefore no changelog entry for you xD
…uct, r=llogiq return_self_not_must_use document `#[must_use]` on the type Inspired by a discussion in rust-lang/rust-clippy#8197 --- r? `@llogiq` changelog: none The lint is this on nightly, therefore no changelog entry for you xD
wrong_self_convention: Match `SelfKind::No` more restrictively
The `wrong_self_convention` lint uses a `SelfKind` type to decide
whether a method has the right kind of "self" for its name, or whether
the kind of "self" it has makes its name confusable for a method in
a common trait. One possibility is `SelfKind::No`, which is supposed
to mean "No `self`".
Previously, SelfKind::No matched everything _except_ Self, including
references to Self. This patch changes it to match Self, &Self, &mut
Self, Box<Self>, and so on.
For example, this kind of method was allowed before:
```
impl S {
// Should trigger the lint, because
// "methods called `is_*` usually take `self` by reference or no `self`"
fn is_foo(&mut self) -> bool { todo!() }
}
```
But since SelfKind::No matched "&mut self", no lint was triggered
(see rust-lang#8142).
With this patch, the code above now gives a lint as expected.
fixes rust-lang#8142
changelog: [`wrong_self_convention`] rejects `self` references in more cases
…xFrednet [`erasing_op`] lint ignored when operation `Output` type is different from the type of constant `0` fixes rust-lang#7210 changelog: [`erasing_op`] lint ignored when operation `Output` type is different from the type of constant `0`
Remove `NullOp::Box` Follow up of rust-lang#89030 and MCP rust-lang/compiler-team#460. ~1 month later nothing seems to be broken, apart from a small regression that rust-lang#89332 (1aac85bb716c09304b313d69d30d74fe7e8e1a8e) shows could be regained by remvoing the diverging path, so it shall be safe to continue and remove `NullOp::Box` completely. r? `@jonas-schievink` `@rustbot` label T-compiler
…rednet
Fix `clippy::use-self`` warning in ` src/main.rs`
`ClippyCmd` warnings gets generated due to addition of `clippy::use-self`. This PR fixes that.
```
warning: unnecessary structure name repetition
--> src/main.rs:99:9
|
99 | ClippyCmd {
| ^^^^^^^^^ help: use the applicable keyword: `Self`
|
= note: `-W clippy::use-self` implied by `-W clippy::nursery`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#use_self
```
---
changelog: none
Consider auto-deref when linting `manual_swap` fixes rust-lang#8154 changelog: Don't lint `manual_swap` when a field access involves auto-deref
Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`
changelog: none Sorry, this is a big one. A lot of interrelated changes and I wanted to put the new utils to use to make sure they are somewhat battle-tested. We may want to divide some of the lint-specific refactoring commits into batches for smaller reviewing tasks. I could also split into more PRs. Introduces a bunch of new utils at `clippy_utils::macros::...`. Please read through the docs and give any feedback! I'm happy to introduce `MacroCall` and various functions to retrieve an instance. It feels like the missing puzzle piece. I'm also introducing `ExpnId` from rustc as "useful for Clippy too". `@rust-lang/clippy` Fixes rust-lang#7843 by not parsing every node of macro implementations, at least the major offenders. I probably want to get rid of `is_expn_of` at some point.
New macro utils changelog: none Sorry, this is a big one. A lot of interrelated changes and I wanted to put the new utils to use to make sure they are somewhat battle-tested. We may want to divide some of the lint-specific refactoring commits into batches for smaller reviewing tasks. I could also split into more PRs. Introduces a bunch of new utils at `clippy_utils::macros::...`. Please read through the docs and give any feedback! I'm happy to introduce `MacroCall` and various functions to retrieve an instance. It feels like the missing puzzle piece. I'm also introducing `ExpnId` from rustc as "useful for Clippy too". `@rust-lang/clippy` Fixes rust-lang#7843 by not parsing every node of macro implementations, at least the major offenders. I probably want to get rid of `is_expn_of` at some point.
Remove in_macro from clippy_utils changelog: none Previously done in rust-lang#7897 but reverted in rust-lang#8170. I'd like to keep `in_macro` out of utils because if a span is from expansion in any way (desugaring or macro), we should not proceed without understanding the nature of the expansion IMO. r? `@llogiq`
`manual_memcpy` fix fixes rust-lang#8160 Ideally this would work with `VecDeque`, but the current interface is unsuitable for it. At a minimum something like `range_as_slices` would be needed. changelog: Don't lint `manual_memcpy` on `VecDeque` changelog: Suggest `copy_from_slice` for `manual_memcpy` when applicable
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 rollup=iffy (includes |
|
@bors r+ |
|
📌 Commit b83c77c has been approved by |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jan 14, 2022
Clippyup r? `@Manishearth`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jan 14, 2022
Clippyup r? ``@Manishearth``
This was referenced Jan 14, 2022
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 14, 2022
…askrgr Rollup of 9 pull requests Successful merges: - rust-lang#92045 (Don't fall back to crate-level opaque type definitions.) - rust-lang#92381 (Suggest `return`ing tail expressions in async functions) - rust-lang#92768 (Partially stabilize `maybe_uninit_extra`) - rust-lang#92810 (Deduplicate box deref and regular deref suggestions) - rust-lang#92818 (Update documentation for doc_cfg feature) - rust-lang#92840 (Fix some lints documentation) - rust-lang#92849 (Clippyup) - rust-lang#92854 (Use the updated Rust logo in rustdoc) - rust-lang#92864 (Fix a missing dot in the main item heading) Failed merges: - rust-lang#92838 (Clean up some links in RELEASES) r? `@ghost` `@rustbot` modify labels: rollup
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Jan 27, 2022
Clippyup 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