This commit fixes a bug introduced in rust-lang#12706, where the behavior of the
lint has been changed, to avoid suggestions that introduce a move. The
motivation in the commit message is quite poor (if the detection for
significant drops is not sufficient because it's not transitive, the
proper fix would be to make it transitive). However, rust-lang#12454, the linked
issue, provides a good reason for the change — if the value being
borrowed is bound to a variable, then moving it will only introduce
friction into future refactorings.

Thus rust-lang#12706 changes the logic so that the lint triggers if the value
being borrowed is Copy, or is the result of a function call, simplifying
the logic to the point where analysing "is this the only use of this
value" isn't necessary.

However, said PR also introduces an undocumented carveout, where
referents that themselves are mutable references are treated as Copy,
to catch some cases that we do want to lint against. However, that is
not sound — it's possible to consume a mutable reference by moving it.

To avoid emitting false suggestions, this PR reintroduces the
referent_used_exactly_once logic and runs that check for referents that
are themselves mutable references.

Thinking about the code shape of &mut x, where x: &mut T, raises the
point that while removing the &mut outright won't work, the extra
indirection is still undesirable, and perhaps instead we should suggest
reborrowing: &mut *x. That, however, is left as possible future work.

Fixes rust-lang#12856

TODO: Should we move `ty::peel_mid_ty_refs_is_mutable` to super module too?

Fixes rust-lang#12751

changelog: Fix [`redundant_slicing`] when the slice is behind a mutable reference

Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing).

Inlining format args prevents accidental `&` misuse.

Co-authored-by: Fridtjof Stoldt <xFrednet@gmail.com>

…-errors

Implement lint against ambiguous negative literals

This PR implements a lint against ambiguous negative literals with a literal and method calls right after it.

## `ambiguous_negative_literals`

(deny-by-default)

The `ambiguous_negative_literals` lint checks for cases that are confusing between a negative literal and a negation that's not part of the literal.

### Example

```rust,compile_fail
-1i32.abs(); // equals -1, while `(-1i32).abs()` equals 1
```

### Explanation

Method calls take precedence over unary precedence. Setting the precedence explicitly makes the code clearer and avoid potential bugs.

<details>
<summary>Old proposed lint</summary>

## `ambiguous_unary_precedence`

(deny-by-default)

The `ambiguous_unary_precedence` lint checks for use the negative unary operator with a literal and method calls.

### Example

```rust
-1i32.abs(); // equals -1, while `(-1i32).abs()` equals 1
```

### Explanation

Unary operations take precedence on binary operations and method calls take precedence over unary precedence. Setting the precedence explicitly makes the code clearer and avoid potential bugs.

</details>

-----

Note: This is a strip down version of rust-lang#117161, without the binary op precedence.

Fixes rust-lang#117155
`@rustbot` labels +I-lang-nominated
cc `@scottmcm`
r? compiler

…ubtree-update

Also get the receiver T in `T.method(|| f())`.

…=xFrednet

Remove unnecessary `res` field in `for_each_expr` visitors

Small refactor in the `for_each_expr*` visitors. This should not change anything functionally.

Instead of storing the final value `Option<B>` in the visitor and setting it to `Some` when we get a `ControlFlow::Break(B)` from the closure, we can just directly return it from the visitor itself now that visitors support that.

cc rust-lang#12829 and rust-lang/rust-clippy#12830 (comment)

changelog: none

… r=xFrednet

needless_borrows_for_generic_args: Fix for &mut

This commit fixes a bug introduced in rust-lang#12706, where the behavior of the lint has been changed, to avoid suggestions that introduce a move. The motivation in the commit message is quite poor (if the detection for significant drops is not sufficient because it's not transitive, the proper fix would be to make it transitive). However, rust-lang#12454, the linked issue, provides a good reason for the change — if the value being borrowed is bound to a variable, then moving it will only introduce friction into future refactorings.

Thus rust-lang#12706 changes the logic so that the lint triggers if the value being borrowed is Copy, or is the result of a function call, simplifying the logic to the point where analysing "is this the only use of this value" isn't necessary.

However, said PR also introduces an undocumented carveout, where referents that themselves are mutable references are treated as Copy, to catch some cases that we do want to lint against. However, that is not sound — it's possible to consume a mutable reference by moving it.

To avoid emitting false suggestions, this PR reintroduces the referent_used_exactly_once logic and runs that check for referents that are themselves mutable references.

Thinking about the code shape of &mut x, where x: &mut T, raises the point that while removing the &mut outright won't work, the extra indirection is still undesirable, and perhaps instead we should suggest reborrowing: &mut *x. That, however, is left as possible future work.

Fixes rust-lang#12856

changelog: none

…endoo

Fix handling of `Deref` in `assigning_clones`

The `assigning_clones` lint had a special case for producing a bit nicer code for mutable references:
```rust
fn clone_function_lhs_mut_ref(mut_thing: &mut HasCloneFrom, ref_thing: &HasCloneFrom) {
    *mut_thing = Clone::clone(ref_thing);
}
//v
fn clone_function_lhs_mut_ref(mut_thing: &mut HasCloneFrom, ref_thing: &HasCloneFrom) {
    Clone::clone_from(mut_thing, ref_thing);
}
```
However, this could [break](rust-lang/rust-clippy#12437) when combined with `Deref`.

This PR removes the special case, so that the generated code should work more generally. Later we can improve the detection of `Deref` and put the special case back in a way that does not break code.

Fixes: rust-lang/rust-clippy#12437

r? `@blyxyas`

changelog: [`assigning_clones`]: change applicability to `Unspecified` and fix a problem with `Deref`.

…tthiaskrgr

Clippy subtree update

r? `@Manishearth`

Updates Cargo.lock due to the Clippy version update and the ui_test bump to v0.24

…hat, r=y21

Make restriction lint's use `span_lint_and_then` (i -> p)

This migrates a few restriction lints to use `span_lint_and_then`. This change is motivated by rust-lang/rust-clippy#7797.

I've also cleaned up some lint message. Mostly minor stuff. For example: suggestions with a longer message than `"try"` now use `SuggestionStyle::ShowAlways`

---

cc: rust-lang/rust-clippy#7797

brother PR of: rust-lang/rust-clippy#13136

changelog: none

Signed-off-by: riyueguang <rustruby@outlook.com>

Bump ui_test version -> 0.25

r? `@Alexendoo`

cc `@GuillaumeGomez`

changelog: none

Avoid ref when using format!

Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing).

Inlining format args prevents accidental `&` misuse.

See also rust-lang#112156

changelog: none

chore: fix some comments

fix some comments

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

changelog: none

Support ?Trait bounds in supertraits and dyn Trait under a feature gate

This patch allows `maybe` polarity bounds under a feature gate. The only language change here is that corresponding hard errors are replaced by feature gates. Example:
```rust
#![feature(allow_maybe_polarity)]
...
trait Trait1 : ?Trait { ... } // ok
fn foo(_: Box<(dyn Trait2 + ?Trait)>) {} // ok
fn bar<T: ?Sized + ?Trait>(_: &T) {} // ok
```
Maybe bounds still don't do anything (except for `Sized` trait), however this patch will allow us to [experiment with default auto traits](rust-lang#120706 (comment)).

This is a part of the [MCP: Low level components for async drop](rust-lang/compiler-team#727)

…tr, r=dtolnay

Stabilize const `{integer}::from_str_radix` i.e. `const_int_from_str`

This PR stabilizes the feature `const_int_from_str`.

- ACP Issue: rust-lang/libs-team#74
- Implementation PR: rust-lang#99322
- Part of Tracking Issue: rust-lang#59133

API Change Diff:

```diff
impl {integer} {
- pub       fn from_str_radix(src: &str, radix: u32) -> Result<Self, ParseIntError>;
+ pub const fn from_str_radix(src: &str, radix: u32) -> Result<Self, ParseIntError>;
}

impl ParseIntError {
- pub       fn kind(&self) -> &IntErrorKind;
+ pub const fn kind(&self) -> &IntErrorKind;
}
```
This makes it easier to parse integers at compile-time, e.g.
the example from the Tracking Issue:

```rust
env!("SOMETHING").parse::<usize>().unwrap()
```

could now be achived  with

```rust
match usize::from_str_radix(env!("SOMETHING"), 10) {
  Ok(val) => val,
  Err(err) => panic!("Invalid value for SOMETHING environment variable."),
}
```

rather than having to depend on a library that implements or manually implement the parsing at compile-time.

---

Checklist based on [Libs Stabilization Guide - When there's const involved](https://std-dev-guide.rust-lang.org/development/stabilization.html#when-theres-const-involved)

I am treating this as a [partial stabilization](https://std-dev-guide.rust-lang.org/development/stabilization.html#partial-stabilizations) as it shares a tracking issue (and is rather small), so directly opening the partial stabilization PR for the subset (feature `const_int_from_str`) being stabilized.

- [x] ping Constant Evaluation WG
- [x] no unsafe involved
- [x] no `#[allow_internal_unstable]`
- [ ] usage of `intrinsic::const_eval_select` rust-lang#124625 in `from_str_radix_assert` to change the error message between compile-time and run-time
- [ ] [rust-labg/libs-api FCP](rust-lang#124941 (comment))

* Detect `BTreeSet::contains` + `BTreeSet::insert` usage in the same way as with the `HashSet`.

…=Manishearth

Make `std_instead_of_core` somewhat MSRV aware

For rust-lang#13158, this catches some things e.g. `core::net` and the recently stable `core::error` but not things moved individually like `UnwindSafe`, as far as I can see the version for those isn't easily available

Beta nominating since ideally we'd get this change in the same version as `core::error` becomes stable

cc `@kpreid`

changelog: none

… r=llogiq

Add `BTreeSet` detection to the `set_contains_or_insert` lint

* Detect `BTreeSet::contains` + `BTreeSet::insert` usage in the same way as with the `HashSet`.
CC: `@lochetti` `@bitfield`

----

changelog: [`set_contains_or_insert`]: Handle `BTreeSet` in addition to `HashSet`

Fix while_let_on_iterator dropping loop label when applying fix.

Loop label was not persisted when displaying help and was therefore producing broken rust code when applying fixes.

Solution was to store the `ast::Label` when creating a `higher::WhileLet` from an expression and add the label name to the lint suggestion and diagnostics.

---

Fixes: rust-lang/rust-clippy#13123

changelog: [`while_let_on_iterator`]: Fix issue dropping loop label when displaying help and applying fixes.

…e-order, r=dswij

`missing_trait_methods`: lint methods in definition order

Lintcheck for rust-lang#13157 showed a bunch of changes for `missing_trait_methods`

This is because `values_sorted` was sorting the entries by the key's [`DefPathHash`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/def_id/struct.DefPathHash.html), this is stable for a given compiler but can change across versions

changelog: none

…ent..

…dnet

Fix display of configs in clippy doc page

Fixes rust-lang/rust-clippy#13051.

It was simply some empty lines missing between configs. With this fix it looks like expected:

![image](https://github.com/user-attachments/assets/89c609b4-e24a-4f4a-91c1-3b49fc83584c)

r? `@xFrednet`

changelog: Fix display of configs in clippy doc page

Fix fix under loop may dropping loop label when applying fix.

changelog: [`explicit_counter_loop`]: fix label drop
changelog: [`for_kv_map`]: add label drop test

Misc changes to `clippy_config`

Contains part of rust-lang#13084

Changes include:
* Sort config list and each configs lint list.
* Add default text for the two configs that were missing it.
* Switch the lint list in the configs to an attribute.
* Make `dev fmt` sort the config list.

r? `@xFrednet`

changelog: none

…, r=Alexendoo

Clean up clippy lints page JS source code

Just a small cleanup for the lints page JS source code.

r? `@Alexendoo`

changelog: Clean up clippy lints page JS source code

Emit `if_let_mutex` in presence of other mutexes

Currently (master, not nightly nor stable) `if_let_mutex` does not emit a warning here:
```rs
let m1 = Mutex::new(10);
let m2 = Mutex::new(());

if let 100..=200 = *m1.lock().unwrap() {
  m2.lock();
} else {
  m1.lock();
}
```
It currently looks for the first call to `.lock()` on *any* mutex receiver inside of the if/else body, and only later (outside of the visitor) checks that the receiver matches the mutex in the scrutinee. That means that in cases like the above, it finds the `m2.lock()` expression, stops the visitor, fails the check that it's the same mutex (`m2` != `m1`) and then does not look for any other `.lock()` calls.

So, just make the receiver check also part of the visitor so that we only stop the visitor when we also find the right receiver.

The first commit has the actual changes described here. The sceond one just unnests all the `if let`s

----

changelog: none

…ovement, r=Alexendoo

Add possibility to focus on search input using keyboard

This PR adds the possibility to focus on the search input with `S` or `/` like in rustdoc and `mdbook` and `docs.rs` (unification++). Pressing escape will blur it.

r? `@Alexendoo`

changelog: Add possibility to focus on search input using keyboard

Remove some miscellaneous `#[allow]`s

Some were unneeded, others were removed by fixing/removing the thing they allow

changelog: none

… r=llogiq

Use a single multipart suggestion for `implicit_hasher`

The second commit individually shows the diagnostic change

----

changelog: none

…config, r=xFrednet

Fix broken list for lints config

Follow-up of rust-lang#13166.

Finally figured out that it was a transformation and not the source that was the problem. It now looks like this:

![Screenshot from 2024-07-29 16-29-10](https://github.com/user-attachments/assets/4b89b3fe-8f85-47b8-8d9a-505badeaeac4)

r? `@xFrednet`

changelog: none

…83, r=Manishearth

Fix false positive for `missing_backticks` in footnote references

Fixes rust-lang#13183.

changelog: Fix false positive for `missing_backticks` in footnote references

Fix `redundant_closure` false positive with closures has return type contains  `'static`

Fix rust-lang#13073 .

Please enable "ignore white-space change" settings in github UI for easy reviewing.

HACK: The third commit contains a hack to check if a type `T: 'static` when `fn() -> U where U: 'static`.
I don't have a clean way to check for it.

changelog: [`redundant_closure`] Fix false positive with closures has return type contains  `'static`

When a suggestion part is for already present code, do not highlight it. If after that there are no highlights left, do not show the suggestion at all.

Fix clippy lint suggestion incorrectly treated as `span_help`.

Fix [`redundant_slicing`] when the slice is behind a mutable reference

Fixes rust-lang#12751

changelog: Fix [`redundant_slicing`] when the slice is behind a mutable reference and a immutable reference is expected.

Remove duplicated `peel_middle_ty_refs`

TODO: Should we move `ty::peel_mid_ty_refs_is_mutable` to super module too?

changelog: none

Add test for `try_err` lint within try blocks.

Fixes rust-lang#5757

Turns out the current `try_err` implementation already skips expressions inside of a try block.

When inside of a try block, `Err(_)?` is desugared to a `break` instead of normal `return` . This makes `find_return_type()` function at [this line](https://github.com/rust-lang/rust-clippy/blob/eb4d88e690c431691bc0fd8eaa9f7096ecc2a723/clippy_lints/src/matches/try_err.rs#L29) always returns `None` and skips the check.

I just added a test case for try block.

changelog: none

…ad_of_collect, r=llogiq

Add clarification for from_iter_instead_of_collect

Close rust-lang#13147

As mentioned at rust-lang#13147 we should prefer to use collect depends on situation so clarify this at documentation and provide examples this cases.

changelog: none

…r=y21

Limit number of `nonminimal_bool` ops

Fixes rust-lang/rust-clippy#11257
Fixes rust-lang/rust-clippy#13206

changelog: none

fix-typos

fixes some typos in lintcheck

changelog: None

Remove `multispan_sugg[_with_applicability]`

They're thin wrappers over the corresponding diag method so we should just use that instead

changelog: none

Check exit status of subcommands spawned by rustc_tools_util

The git commands `git rev-parse --short HEAD` and `git log -1 --date=short --pretty=format:%cd` that clippy runs from its build script might fail with **"fatal: not a git repository (or any of the parent directories): .git"** if clippy is being built from a source tarball rather than a git repository. That message is written by git to stderr, and nothing is written to stdout.

For `clippy-driver --version` this PR wouldn't make a difference because it treats empty stdout and failed spawns (`git` is not installed) identically:

https://github.com/rust-lang/rust-clippy/blob/7ac242c3d0d3ee867a6c9cdcbdec986c408ac36f/rustc_tools_util/src/lib.rs#L35-L42

But other users of `rustc_tools_util` should be able to expect that the distinction between Some and None is meaningful. They shouldn't need extra code to handle None vs Some-and-empty vs Some-and-nonempty.

---

changelog: none

Remove legacy deprecations.
Remove "View Source" link for deprecated lints.

Simplify lint deprecation

A couple of small changes:
* A few deprecations were changed to renames. They all had a message similar to "this lint has been replaced by ..." which is just describing a rename.
* The website and warning message are now the same. The website description was usually just a wordier version that contained no extra information. This can be worked around if needed, but I don't think that will happen.
* The legacy deprecations have been removed. rustc should handle this since it already suggests adding the `clippy::` for all lints (deprecated or not) when they're used without it. It wouldn't be a problem to add them back in.
* The website no longer has a "view source" link for deprecated lints since they're no longer read from the HIR tree. I could store the line number, but the link seems totally useless for these lints.

This came up as part of separating the internal lints into their own crate. Both the metadata collector and the lint registration code needs access to the deprecated and renamed lists. This form lets all the deprecations be a separate crate.

r? `@flip1995`

changelog: none

…r=blyxyas

Make restriction lint's use `span_lint_and_then` (a -> e)

This migrates a few restriction lints to use `span_lint_and_then`. This change is motivated by rust-lang/rust-clippy#7797.

I'm also interested if it will have an impact on performance. With some of these lints, like [`clippy::implicit_return`](https://rust-lang.github.io/rust-clippy/master/index.html#/implicit_return) I expect an impact, as it was previously creating a suggestion **for every implicit return** which is just wild.

I've also cleaned up some lint message. Mostly minor stuff. For example: suggestions with a longer message than `"try"` now use `SuggestionStyle::ShowAlways`

---

`@blyxyas` Could you benchmark this PR? I want to get all the numbers :3

---

This also crashed our new lintcheck CI with the following message:

> Error: $GITHUB_STEP_SUMMARY upload aborted, supports content up to a size of 1024k, got 46731k. For more information see: https://docs.github.com/actions/using-workflows/workflow-commands-for-github-actions#adding-a-markdown-summary

Which is just wild. Like, I've [tested the first 20 lints](https://github.com/xFrednet/rust-clippy/actions/runs/10027528172) and got like four changes and then this. 50 MB of changed lint messages o.O. Looks like I'll create a separate PR to fix that step ^^

---

cc: rust-lang/rust-clippy#7797

changelog: none

r? `@blyxyas`

…1995

Use a deterministic number of digits in rustc_tools_util commit hashes

Using `git rev-parse --short` in rustc_tools_util causes nondeterministic compilation of projects that use `setup_version_info!` and `get_version_info!` when built from the exact same source code and git commit. The number of digits printed by `--short` is sensitive to how many other branches and tags in the repository have been fetched so far, what other commits have been worked on in other branches, how recently you had run `git gc`, platform-specific variation in git's default configuration, and platform differences in the sequence of steps performed by the release pipeline. Someone can compile a tool from a particular commit, switch branches to work on a different commit (or simply do a git fetch), go back to the first commit and be unable to reproduce the binary that was built from it previously.

Currently, variation in short commit hashes causes Clippy version strings to be out of sync between different targets. On x86_64-unknown-linux-gnu:

```console
$ clippy-driver +1.80.0 --version
clippy 0.1.80 (0514789 2024-07-21)
```

Whereas on aarch64-apple-darwin:

```console
$ clippy-driver +1.80.0 --version
clippy 0.1.80 (0514789 2024-07-21)
```

---

changelog: none