Suggested by @xFrednet and @matthiaskrgr.

…ubtree-update

Have the lint trigger even if `Self` has generic lifetime parameters.

```rs
impl<'a> Foo<'a> {
    type Item = Foo<'a>; // Can be replaced with Self

    fn new() -> Self {
        Foo { // No lifetime, but they are inferred to be that of Self
              // Can be replaced as well
            ...
        }
    }

    // Don't replace `Foo<'b>`, the lifetime is different!
    fn eq<'b>(self, other: Foo<'b>) -> bool {
        ..
    }
```

Fixes rust-lang#12381

Add asm goto support to `asm!`

Tracking issue: rust-lang#119364

This PR implements asm-goto support, using the syntax described in "future possibilities" section of [RFC2873](https://rust-lang.github.io/rfcs/2873-inline-asm.html#asm-goto).

Currently I have only implemented the `label` part, not the `fallthrough` part (i.e. fallthrough is implicit). This doesn't reduce the expressive though, since you can use label-break to get arbitrary control flow or simply set a value and rely on jump threading optimisation to get the desired control flow. I can add that later if deemed necessary.

r? ``@Amanieu``
cc ``@ojeda``

fix [`missing_docs_in_private_items`] on some proc macros

fixes: rust-lang#12197

---

changelog: [`missing_docs_in_private_items`] support manually search for docs as fallback method

…enkov

Refactor pre-getopts command line argument handling

Rebased version of rust-lang#111658. I've also fixed the Windows CI failure (although I don't have access to Windows to test it myself).

Lint singleton gaps after exclusive ranges

In the discussion to stabilize exclusive range patterns (rust-lang#37854), it has often come up that they're likely to cause off-by-one mistakes. We already have the `overlapping_range_endpoints` lint, so I [proposed](rust-lang#37854 (comment)) a lint to catch the complementary mistake.

This PR adds a new `non_contiguous_range_endpoints` lint that catches likely off-by-one errors with exclusive range patterns. Here's the idea (see the test file for more examples):
```rust
match x {
    0..10 => ..., // WARN: this range doesn't match `10_u8` because `..` is an exclusive range
    11..20 => ..., // this could appear to continue range `0_u8..10_u8`, but `10_u8` isn't matched by either of them
    _ => ...,
}
// help: use an inclusive range instead: `0_u8..=10_u8`
```

More precisely: for any exclusive range `lo..hi`, if `hi+1` is matched by another range but `hi` isn't, we suggest writing an inclusive range `lo..=hi` instead. We also catch `lo..T::MAX`.

New lint `const_is_empty`

This lint detects calls to `.is_empty()` on an entity initialized from a string literal and flag them as suspicious. To avoid triggering on macros called from generated code, it checks that the `.is_empty()` receiver, the call itself and the initialization come from the same context.

Fixes rust-lang#12307

changelog: [`const_is_empty`]: new lint

… `duplicated_attributes`

…gs, r=Alexendoo

[`no_effect_replace`]: Fix duplicate diagnostics

Relates to rust-lang#12379

Fixes `no_effect_replace` duplicate diagnostics

---

changelog: [`no_effect_replace`]: Fix duplicate diagnostics

…r=y21

[`mut_mut`]: Fix duplicate diags

Relates to rust-lang#12379

The `mut_mut` lint produced two diagnostics for each `mut mut` pattern in `ty` inside  `block`s because `MutVisitor::visit_ty` was called from `MutMut::check_ty` and  `MutMut::check_block` independently. This PR fixes the issue.

---

changelog: [`mut_mut`]: Fix duplicate diagnostics

use `span_lint_hir` instead of `span_lint` in more lints

Decided to grep for `check_(fn|block)` and look where `span_lint` is used, since some lints lint will then emit a lint on a statement or expression in that function, which would use the wrong lint level attributes

The `LintContext` keeps track of the last entered HIR node that had any attributes, and uses those (and its parents) for figuring out the lint level when a lint is emitted

However, this only works when we actually emit a lint at the same node as the `check_*` function we are in.
If we're in `check_fn` and we emit a lint on a statement within that function, then there is no way to allow the lint only for that one statement (if `span_lint` is used). It would only count allow attributes on the function

changelog: [`needless_return`]: [`useless_let_if_seq`]: [`mut_mut`]: [`read_zero_byte_vec`]: [`unused_io_amount`]: [`unused_peekable`]: now respects `#[allow]` attributes on the affected statement instead of only on the enclosing block or function

…_methods

Add new lint `zero_repeat_side_effects`

Fixes rust-lang/rust-clippy#6439

Adds a new `suspicious` lint zero_repeat_side_effects. This lint warns the user when initializing an array or `Vec` using the `Repeat` syntax, i.e., `[x; y]`. If `x` is an `Expr::Call/MethodCall` or contains an `Expr::Call/MethodCall` and `y` is zero, then there is a chance that the internal call can produce side effects, such as printing to console, which is not very obvious.

This lint warns against this and instead suggests to separate out the function call and the array/Vec initialization.

changelog: Add new lint `zero_repeat_side_effects`

…r=y21

Fix rust-lang#12438 std_instead_of_core regression

Fixes rust-lang#12438.

Boy-scouting removed two paths that checks for duplication since I thought they were unused. However, that's just because I didn't spot it in the diff.

I installed [difftastic](https://github.com/Wilfred/difftastic) and ran it on the old one:

![image](https://github.com/rust-lang/rust-clippy/assets/34198073/5c51276c-055a-49a3-9425-6f7da0590fb0)

And the new one (fixed):

![image](https://github.com/rust-lang/rust-clippy/assets/34198073/6e10f29c-6d6b-4f64-893f-de526424f1cd)

New one (stderr):
![image](https://github.com/rust-lang/rust-clippy/assets/34198073/c4c07776-ee0f-47ba-996f-6b632de47c81)

Good teachings for the future when inspecting diffs with a lot of line changes, should've thought of that before, sorry for the trouble!

changelog: [`std_instead_of_core`] Fix false positive for crates that are in `std` but not `core`

…=RalfJung

Distinguish between library and lang UB in assert_unsafe_precondition

As described in rust-lang#121583 (comment), `assert_unsafe_precondition` now explicitly distinguishes between language UB (conditions we explicitly optimize on) and library UB (things we document you shouldn't do, and maybe some library internals assume you don't do).

`debug_assert_nounwind` was originally added to avoid the "only at runtime" aspect of `assert_unsafe_precondition`. Since then the difference between the macros has gotten muddied. This totally revamps the situation.

Now _all_ preconditions shall be checked with `assert_unsafe_precondition`. If you have a precondition that's only checkable at runtime, do a `const_eval_select` hack, as done in this PR.

r? RalfJung

Miri subtree update

r? `@ghost`

`@WaffleLapkin` when this lands, setting `MIRI_TEMP` should not be needed any more on the dev desktops.

…efault, r=llogiq

Add new `manual_unwrap_or_default` lint

This adds a new lint checking if a `match` or a `if let` can be replaced with `unwrap_or_default`.

----

changelog: Add new [`manual_unwrap_or_default`] lint

…dnet

add documentation to the `span_lint_hir` functions

As far as I could tell, these weren't documented anywhere, and since this is sometimes needed over `span_lint` for `#[allow]` attrs to work, I thought I would add a little bit of documentation.
When I started with clippy development, I also had no idea what these functions were for.

changelog: none

…vement, r=dswij

[`seek_from_current`]: readability improvements

fixes rust-lang#12457.

---

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

changelog: [`seek_from_current`]: readability improvements

[`single_match`]: Fix duplicate diagnostics

Relates to rust-lang#12379

edit two test file
`tests/ui/single_match_else.rs`
`tests/ui/single_match.rs`

those two test file point to the same lint

---

changelog: [`single_match`] Fix duplicate diagnostics

…exendoo

Fix dependency specifications

As Clippy lacks `Cargo.lock`, it makes sense to test its dependency specifications with [direct-minimal-versions](https://doc.rust-lang.org/cargo/reference/unstable.html#direct-minimal-versions). This can be done with the following addition to `.cargo/config.toml`.

```toml
[unstable]
direct-minimal-versions = true
```

* `tempfile` 3.3 is required by `clippy_lints`.
* `regex` 1.5.5 is required by `ui_test` 0.22.2.
* `quote` 1.0.25 is required by `syn` 2.0.0.
* `serde` 1.0.145 is required by `toml` 0.7.3.

changelog: none

The struct returned by the `Span::ctxt` method was listed as
`SpanContext`. The correct struct is currently named `SyntaxContext`.

…xyas

Add new `duplicated_attributes` lint

It's a lint idea that `@llogiq` gave me while reviewing another PR.

There are some limitations, in particular for the "output". Initially I wanted to make it possible for directly lint against the whole attribute if its parts were all duplicated, but then I realized that the output would be chaotic if the duplicates were coming from different attributes, so I preferred to go to the simplest way and simply emit a warning for each entry. Not the best, but makes the implementation much easier.

Another limitation is that `cfg_attr` would be a bit more tricky to implement because we need to check if two `cfg` sets are exactly the same. I added a FIXME and will likely come back to it later.

And finally, I updated the `cargo dev update_lints` command because the generated `tests/ui/rename.rs` file was emitting the `duplicated_attributes` lint, so I allowed this lint inside it to prevent it from working.

changelog: Add new `duplicated_attributes` lint

[`manual_retain`]: Fix duplicate diagnostics

Relates to: rust-lang#12379

The first lint guard executed in `LateLintPass::check_expr` was testing if the parent was of type `ExprKind::Assign`.  This meant the lint emitted on both sides of the assignment operator when `check_expr` is called on either `Expr`.  The guard in the fix only lints once when the `Expr` is of kind `Assign`.

changelog:  Fix duplicate lint diagnostic emission from [`manual_retain`]

Will be used in the next commit

Signed-off-by: pavedroad <qcqs@outlook.com>

Fix typo in section '6.10. Macro Expansions' of the Clippy Book

Under the "Span.ctxt method" heading in *Section 6.10. Macro Expansions* of the *Clippy Book*, the type returned by the
`Span::ctxt` method is listed as `SpanContext`.  The correct type name should be `SyntaxContext`.

---

changelog: Fixed typo in "Section 6.10. Macro Expansions" of the Clippy Book. `SpanContext` changed to `SyntaxContext`.

Move `iter_nth` to `style`, add machine applicable suggestion

There's no `O(n)` involved with `.iter().nth()` on the linted types since the iterator implementations provide `nth` and/or `advance_by` that operate in `O(1)`

For slice iterators the codegen is equivalent, `VecDeque`'s iterator seems to codegen differently but that doesn't seem significant enough to keep it as a perf lint

changelog: [`iter_nth`] Move to `style`

r? `@flip1995`

chore: fix some typos

Thank you for making Clippy better!

We're collecting our changelog from pull request descriptions.
If your PR only includes internal changes, you can just write
`changelog: none`. Otherwise, please write a short comment
explaining your change.

It's also helpful for us that the lint name is put within backticks (`` ` ` ``),
and then encapsulated by square brackets (`[]`), for example:
```
changelog: [`lint_name`]: your change
```

If your PR fixes an issue, you can add `fixes #issue_number` into this
PR description. This way the issue will be automatically closed when
your PR is merged.

If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.

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

[lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints

Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.

Delete this line and everything above before opening your PR.

---

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

changelog:

[`cast_lossless`]: Suggest type alias instead of the aliased type

Fixes rust-lang#11285

Still an issue with the "from" side, i.e., `I8::from(1) as I64` shows as `i8 to I64`, but this should be ok. Not possible to reliably fix currently anyway.

changelog: [`cast_lossless`]: Suggest type alias instead of the aliased type

fix [`empty_docs`] trigger in proc-macro

fixes: rust-lang#12377

---

changelog: fix [`empty_docs`] trigger in proc-macros

…, r=Jarcho

lint when calling the blanket `Into` impl from a `From` impl

Closes rust-lang#11150
```
warning: function cannot return without recursing
  --> x.rs:9:9
   |
9  | /         fn from(value: f32) -> Self {
10 | |             value.into()
11 | |         }
   | |_________^
   |
note: recursive call site
  --> x.rs:10:13
   |
10 |             value.into()
   |             ^^^^^^^^^^^^
```

I'm also thinking that we can probably generalize this lint to rust-lang#11032 at some point (instead of hardcoding a bunch of impls), like how rustc's `unconditional_recursion` works, at least up to one indirect call, but this still seems useful for now :)

I've also noticed that we use `fn_def_id` in a bunch of lints and then try to get the node args of the call in a separate step, so I made a helper function that does both in one. I intend to refactor a bunch of uses of `fn_def_id` to use this later

I can add more test cases, but this is already using much of the same logic that exists for the other impls that this lint looks for (e.g. making sure that there are no conditional returns).

changelog: [`unconditional_recursion`]: emit a warning inside of `From::from` when unconditionally calling the blanket `.into()` impl

… quote

filetime::FileTime::now() is new in 0.2.9

Clippy makes a use of `filetime::FileTime::now()`, which is new in `filetime` 0.2.9.

changelog: none

The lint used to check for patterns looking like:
```rs
for (_, x) in some_iter.enumerate() {
    // Index is ignored
}
```

This commit further checks for chained method calls constructs where we
can detect that the index is unused. Currently, this checks only for the
following patterns:
```rs
some_iter.enumerate().map_function(|(_, x)| ..)
let x = some_iter.enumerate();
x.map_function(|(_, x)| ..)
```
where `map_function` is one of `all`, `any`, `filter_map`, `find_map`,
`flat_map`, `for_each` or `map`.

Fixes rust-lang#12411.

some refractoring;

Handle false positive with `map_clone` lint

### Summary

- Fixes rust-lang/rust-clippy#12271
- (This is my first contribution to clippy and any suggestion would be appreciated)

changelog: [`map_clone`]: Handle false positive with `map_clone` lint

CI: replace `cancel-outdated-builds` with `concurrency` group

This is the last remaining [usage](https://github.com/search?q=org%3Arust-lang%20cancel-outdated-builds&type=code) of the [cancel-outdated-builds](https://github.com/rust-lang/simpleinfra/tree/master/github-actions/cancel-outdated-builds) CI action. Which means that if we remove its usage, we can remove the code of the action :)

This action was replaced in `rust-lang/rust` with the native Github Actions `concurrency` group [last year](rust-lang#112955).

Note that unlike `rust-lang/rust`, which explicitly allows parallel try builds, `clippy` did not allow them, as all steps of the `clippy_bors.yaml` workflow used the `cancel-outdated-builds` action, regardless of the branch. So the new `concurrency` group mirrors that, which makes it a bit simpler than on `rust-lang/rust`.

changelog: none

r? `@Mark-Simulacrum`

[`use_self`]: Make it aware of lifetimes

Have the lint trigger even if `Self` has generic lifetime parameters.

```rs
impl<'a> Foo<'a> {
    type Item = Foo<'a>; // Can be replaced with Self

    fn new() -> Self {
        Foo { // No lifetime, but they are inferred to be that of Self
              // Can be replaced as well
            ...
        }
    }

    // Don't replace `Foo<'b>`, the lifetime is different!
    fn eq<'b>(self, other: Foo<'b>) -> bool {
        ..
    }
```

Fixes rust-lang#12381

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

changelog: [`use_self`]: Have the lint trigger even if `Self` has generic lifetime parameters

Also replace a few `hir_node()` calls with `hir_node_by_def_id()`