Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Rollup of 10 pull requests #92880

Closed
wants to merge 124 commits into from

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
…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`
flip1995 and others added 17 commits January 13, 2022 13:18
…woerister

Implement raw-dylib support for windows-gnu

Add support for `#[link(kind = "raw-dylib")]` on windows-gnu targets.  Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of ``@mati865's`` earlier attempt at this strategy in PR rust-lang#88801.  (In particular, this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.)

In support of rust-lang#58713.
Don't fall back to crate-level opaque type definitions.

That would just hide bugs, as it works accidentally if the opaque type is defined at the crate level.

Only works after rust-lang#90948 which worked by accident for our entire test suite.
… r=Mark-Simulacrum

Partially stabilize `maybe_uninit_extra`

This covers:

```rust
impl<T> MaybeUninit<T> {
    pub unsafe fn assume_init_read(&self) -> T { ... }
    pub unsafe fn assume_init_drop(&mut self) { ... }
}
```

It does not cover the const-ness of `write` under `const_maybe_uninit_write` nor the const-ness of `assume_init_read` (this commit adds `const_maybe_uninit_assume_init_read` for that).

FCP: rust-lang#63567 (comment).

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
…ef-suggestion, r=camelid

Deduplicate box deref and regular deref suggestions

Remove the suggestion code special-cased for Box deref.

r? ``@camelid``
since you introduced the code in rust-lang#90627
…r=camelid

Update documentation for doc_cfg feature

Fixes  rust-lang#92484.
…-Simulacrum

Clean up some links in RELEASES

This fixes some issues with markdown links in the RELEASES file.
Fix some lints documentation

Several lints documentation failed to show the output of the example (mostly due to `ignore` attribute):

- [irrefutable_let_patterns](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#irrefutable-let-patterns)
- [asm_sub_register](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#asm-sub-register)
- [bad_asm_style](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#bad-asm-style)
- [ineffective_unstable_trait_impl](https://doc.rust-lang.org/rustc/lints/listing/deny-by-default.html#ineffective-unstable-trait-impl)
- duplicate_macro_attributes

This pull request fixes these lints output so that they can be displayed properly.
…Gomez

Use the updated Rust logo in rustdoc

This pull-request use the updated Rust logo from rust-lang/rust-artwork#9 and also change the logo format from PNG to SVG.

| Before | After |
| --- | --- |
| ![Screenshot 2022-01-13 at 14-33-40 std - Rust](https://user-images.githubusercontent.com/3616612/149342697-7afe4c3e-2be5-444b-86f3-118712b4f7ae.png) | ![Screenshot 2022-01-13 at 14-33-15 std - Rust](https://user-images.githubusercontent.com/3616612/149342705-54ed27c6-0806-4c2d-baa1-4d65ed897e2b.png) |

I also took the liberty to update the two PNG favicons with the SVG reducing their size by ~35% each.

Fixes rust-lang#92831

r? ``@jsha``
Fix a missing dot in the main item heading

This pull-request fix a missing `·` in the item header ~~and also make use of `&nbsp;` to explicit that the spaces are mandatory~~.

| Before | After |
| --- | --- |
| ![image](https://user-images.githubusercontent.com/3616612/149393966-7cca6dc5-9a62-47fa-8c9c-18f936d43aa9.png) | ![image](https://user-images.githubusercontent.com/3616612/149393869-5ffd6e44-d91c-4ece-b69e-d103304f6626.png) |

PS: This was introduce yesterday by rust-lang#92526 (the migration from Tera to Askama) and is not currently observable in the nightly doc.
@rustbot rustbot added 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. rollup A PR which is a rollup labels Jan 14, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=10

@bors
Copy link
Contributor

bors commented Jan 14, 2022

📌 Commit a5ac242 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

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout rollup-s4fauzz (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self rollup-s4fauzz --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
Removing src/tools/clippy/tests/cargo/mod.rs
Removing src/test/ui/rfc-2627-raw-dylib/raw-dylib-msvc-only.stderr
Removing src/test/ui/rfc-2627-raw-dylib/raw-dylib-msvc-only.rs
Removing src/test/ui/feature-gates/feature-gate-raw-dylib-windows-gnu.stderr
Removing src/test/ui/feature-gates/feature-gate-raw-dylib-windows-gnu.rs
Removing src/librustdoc/html/static/images/rust-logo.png
Auto-merging compiler/rustc_infer/src/infer/opaque_types.rs
Auto-merging RELEASES.md
CONFLICT (content): Merge conflict in RELEASES.md
Auto-merging Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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
@bors
Copy link
Contributor

bors commented Jan 14, 2022

☔ The latest upstream changes (presumably #92844) made this pull request unmergeable. Please resolve the merge conflicts.

@matthiaskrgr matthiaskrgr deleted the rollup-s4fauzz branch February 13, 2022 00:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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.