Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Rollup of 9 pull requests #92883

Merged
merged 118 commits into from
Jan 14, 2022
Merged

Rollup of 9 pull requests #92883

merged 118 commits into from
Jan 14, 2022

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

nbdd0121 and others added 30 commits October 20, 2021 19:42
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.
@rustbot rustbot added the rollup A PR which is a rollup label Jan 14, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=9

@bors
Copy link
Contributor

bors commented Jan 14, 2022

📌 Commit 2ae4afd has been approved by matthiaskrgr

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jan 14, 2022
@bors
Copy link
Contributor

bors commented Jan 14, 2022

⌛ Testing commit 2ae4afd with merge 6d6ff03543e07b9152b485017f0a8abd84351a32...

@bors
Copy link
Contributor

bors commented Jan 14, 2022

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 14, 2022
@matthiaskrgr
Copy link
Member Author

matthiaskrgr commented Jan 14, 2022

@bors retry x86_64-msvc-1 hang or timeout
https://github.com/rust-lang-ci/rust/runs/4815055569?check_suite_focus=true#logs

Fri, 14 Jan 2022 10:38:09 GMT [TIMING] Crate { compiler: Compiler { stage: 2, host: TargetSelection { triple: "x86_64-pc-windows-msvc", file: None } }, target: TargetSelection { triple: "x86_64-pc-windows-msvc", file: None }, mode: Rustc, test_kind: Test, krate: "rustc_log" } -- 1.996
Fri, 14 Jan 2022 10:38:09 GMT [TIMING] CrateLibrustc { compiler: Compiler { stage: 2, host: TargetSelection { triple: "x86_64-pc-windows-msvc", file: None } }, target: TargetSelection { triple: "x86_64-pc-windows-msvc", file: None }, test_kind: Test, krate: "rustc_log" } -- 0.000
Fri, 14 Jan 2022 10:38:09 GMT Set({"compiler\\rustc_macros"}) not skipped for "bootstrap::test::CrateLibrustc" -- not in ["src/test/ui", "src/tools/linkchecker"]
Fri, 14 Jan 2022 10:38:09 GMT Testing rustc_macros stage1 (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc)
Fri, 14 Jan 2022 10:38:10 GMT [RUSTC-TIMING] build_script_build test:false 0.817
Fri, 14 Jan 2022 10:38:10 GMT [RUSTC-TIMING] unicode_xid test:false 0.171
Fri, 14 Jan 2022 10:38:10 GMT [RUSTC-TIMING] build_script_build test:false 0.762
Fri, 14 Jan 2022 10:38:10 GMT [RUSTC-TIMING] proc_macro2 test:false 2.057
Fri, 14 Jan 2022 10:38:10 GMT [RUSTC-TIMING] quote test:false 0.854
Fri, 14 Jan 2022 10:38:10 GMT [RUSTC-TIMING] syn test:false 19.046
Fri, 14 Jan 2022 10:38:10 GMT [RUSTC-TIMING] synstructure test:false 2.317
Fri, 14 Jan 2022 10:38:10 GMT [RUSTC-TIMING] rustc_macros test:false 5.005
Fri, 14 Jan 2022 10:38:10 GMT    Compiling rustc_macros v0.1.0 (D:\a\rust\rust\compiler\rustc_macros)
Fri, 14 Jan 2022 15:38:55 GMT Error: The operation was canceled.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 14, 2022
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@bors
Copy link
Contributor

bors commented Jan 14, 2022

⌛ Testing commit 2ae4afd with merge ad46af2...

@klensy
Copy link
Contributor

klensy commented Jan 14, 2022

Fri, 14 Jan 2022 10:38:10 GMT Compiling rustc_macros v0.1.0 (D:\a\rust\rust\compiler\rustc_macros)
Fri, 14 Jan 2022 15:38:55 GMT Error: The operation was canceled.

Last few fails was on rustc_macros too.

@bors
Copy link
Contributor

bors commented Jan 14, 2022

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing ad46af2 to master...

@rust-timer
Copy link
Collaborator

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

@matthiaskrgr matthiaskrgr deleted the rollup-uoudywx branch February 13, 2022 00:53
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.