…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

…nst one

…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

…st equal hashes

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`

… r=llogiq

Fix `type_repetition_in_bounds`

fixes rust-lang#7360
fixes rust-lang#8162
fixes rust-lang#8056

changelog: Check for full equality in `type_repetition_in_bounds` rather than just equal hashes

…logiq

Better detect when a field can be moved from in `while_let_on_iterator`

fixes rust-lang#8113

changelog: Better detect when a field can be moved from in `while_let_on_iterator`

…ect`

…n the implementation

… r=xFrednet

Allow running lintcheck with a renamed rust-clippy dir

I have Clippy checked out in `rust/clippy` rather than `rust/rust-clippy`, this allows lintcheck to still run in that case

changelog: none

Change `unnecessary_to_owned` `into_iter` suggestions to `MaybeIncorrect`

I am having a hard time finding a good solution for rust-lang#8148, so I am wondering if is enough to just change the suggestion's applicability to `MaybeIncorrect`?

I apologize, as I realize this is a bit of a cop out.

changelog: none

Fixes rust-lang#8248

According to https://doc.rust-lang.org/cargo/reference/unstable this
seems to be the right place to set it, and it does fix the build for me.

I haven't removed the other `rustflags` because perhaps it's needed on
different cargo/rust versions?

Set binary-dep-depinfo in .cargo/config.toml

Fixes rust-lang#8248

According to https://doc.rust-lang.org/cargo/reference/unstable this
seems to be the right place to set it, and it does fix the build for me.

I haven't removed the other `rustflags` because perhaps it's needed on
different cargo/rust versions?

---

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: none

…n(_untracked)`

And `each_child_of_item` to `for_each_module_child`

This pull request adds a lint against single character lifetime names, as they might not divulge enough information about the purpose of the lifetime. This can make code harder to understand. I placed this in `restriction` rather than `pedantic` (as suggested in rust-lang#8233) since most of the Rust ecosystem already uses single character lifetime names (to my knowledge, at least) and since single character lifetime names aren't incorrect. I'd be happy to change this upon request, however. Fixes rust-lang#8233.

- [x] Followed lint naming conventions
- [x] Added passing UI tests (including committed `.stderr` file)
- [x] `cargo test` passes locally
- [x] Executed `cargo dev update_lints`
- [x] Added lint documentation
- [x] Run `cargo dev fmt`

changelog: new lint: [`single_char_lifetime_names`]

…mes, r=llogiq

new lint: `single_char_lifetime_names`

This pull request adds a lint against single character lifetime names, as they might not divulge enough information about the purpose of the lifetime. This can make code harder to understand. I placed this in `restriction` rather than `pedantic` (as suggested in rust-lang#8233) since most of the Rust ecosystem already uses single character lifetime names (to my knowledge, at least) and since single character lifetime names aren't incorrect. I'd be happy to change this upon request, however. Fixes rust-lang#8233.

- [x] Followed lint naming conventions
- [x] Added passing UI tests (including committed `.stderr` file)
- [x] `cargo test` passes locally
- [x] Executed `cargo dev update_lints`
- [x] Added lint documentation
- [x] Run `cargo dev fmt`

changelog: new lint: [`single_char_lifetime_names`]

cover trait for `trait_duplication_in_bounds`

closes rust-lang#8229

changelog: [`trait_duplication_in_bounds`] covers trait functions with `Self` bounds

Combine internal cargo features

changelog: none

This is just simpler and I don't see any downsides.

…5, r=giraffate

fix `iter_not_returning_iterator`

fixes rust-lang#8225

changelog: Handle type projections in `iter_not_returning_iterator`
changelog: Don't lint `iter_not_returning_iterator` in trait implementations
changelog: Lint `iter_not_returning_iterator` in trait definitions

I believe this is possible as of rust-lang/rust-clippy#7631

The two dogfood tests cannot be run concurrently since they use the same
target directory.

This was more valuable when we used the latest nightly without
specifying the toolchain version.

Warn disallowed_methods and disallowed_types by default

Closes rust-lang#7841

changelog: Moved [`disallowed_methods`] and [`disallowed_types`] to `style`

Downgrade mutex_atomic to nursery

See rust-lang#1516 and rust-lang#4295.

There are suggestions about removing this lint from the default warned lints in both issues.
Also, [`mutex_integer`](https://rust-lang.github.io/rust-clippy/master/index.html#mutex_integer) lint that has the same problems as this lint is in `nursery` group.

changelog: Moved [`mutex_atomic`] to `nursery`

Closes: rust-lang#6995

Signed-off-by: Federico Guerinoni <guerinoni.federico@gmail.com>
Co-authored-by: Paolo Barbolini <paolo@paolo565.org>

Currently, `clippy-driver` may run codegen, but this is an
implementation detail.

See rust-lang/rust-clippy#8035.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Removes the "compiled from source" bit, which is confusing.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

The field is also renamed from `ident` to `name. In most cases,
we don't actually need the `Span`. A new `ident` method is added
to `VariantDef` and `FieldDef`, which constructs the full `Ident`
using `tcx.def_ident_span()`. This method is used in the cases
where we actually need an `Ident`.

This makes incremental compilation properly track changes
to the `Span`, without all of the invalidations caused by storing
a `Span` directly via an `Ident`.

Add borrow_as_ptr lint

Closes: rust-lang#6995

- \[x] Followed [lint naming conventions][lint_naming]
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[x] Executed `cargo dev update_lints`
- \[x] Added lint documentation
- \[x] Run `cargo dev fmt`

---

changelog: new lint: [`borrow_as_ptr`]

This covers:

    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>

…, r=camsteffen

Improve documentation for `borrowed-box` lint

fixes rust-lang#8161

Updates documentation to elaborate more on how removing Box from a function parameter can generalize the function.

changelog: none

…expansions

Fix `deref_addrof`

fixes rust-lang#8247

This would supersede rust-lang#8259

changelog: Don't lint `deref_addrof` when the dereference and the borrow occur in different contexts

…p1995

Remove method_call! macro

This is possible now that `SymbolStr` is removed from rustc.

changelog: none

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

…ip1995

Stop using `in_band_lifetimes`

Per rust-lang#91867

changelog: none

`README`: document that Clippy may change codegen

Currently, Clippy does not guarantee the same codegen will be produced.
Therefore, it should not be used as an universal replacement for `rustc`.

See rust-lang/rust-clippy#8035.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

fixes rust-lang#8035
changelog: document that Clippy may change codegen

…1995

Add `manual_bits` lint

Closes rust-lang#6670

---

changelog: new lint: [`manual_bits`]

Since def_path_str returns e.g. "core::f32::<impl f32>::clamp" for
"f32::clamp"

…s, r=flip1995

Allow primitive types in disallowed_methods

Fixes rust-lang#8079

changelog: `disallowed_methods`: Now can disallow methods of primitive types

Cache rustfmt path

changelog: none

Call `rustup which rustfmt` and use the output. This shaves off  ~0.7 seconds for `cargo dev fmt` for me.

Some test code cleanup

changelog: none

Mainly moves /clippy_workspace_tests into /tests and combines the two dogfood tests which can't run concurrently.

`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