Conversation
This amends off of an existing test introduced in rust-lang#81769, if you think I should make a separate test I will.
…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.
|
@bors r+ rollup=never p=9 |
|
📌 Commit 2ae4afd has been approved by |
|
⌛ Testing commit 2ae4afd with merge 6d6ff03543e07b9152b485017f0a8abd84351a32... |
|
💥 Test timed out |
|
@bors retry x86_64-msvc-1 hang or timeout |
Last few fails was on rustc_macros too. |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (ad46af2): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Successful merges:
returning tail expressions in async functions #92381 (Suggestreturning tail expressions in async functions)maybe_uninit_extra#92768 (Partially stabilizemaybe_uninit_extra)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup