- remove now dead code in ASSERTIONS_ON_CONSTANTS
  cc rust-lang#11966
- Partially revert "ignore `assertions-on-constants` in const contexts"
  This reverts commit c7074de420a2192fb40d3f2194a20dd0d1b65cc6.

…ubtree-update

This change addresses cases where doc comments are separated
by blank lines, comments, or non-doc-comment attributes,
like this:

```rust
/// - first line
// not part of doc comment
/// second line
```

Before this commit, Clippy gave a pedantically-correct
warning about how you needed to indent the second line.
This is unlikely to be what the user intends, and has
been described as a "false positive" (since Clippy is
warning you about a highly unintuitive behavior that
Rustdoc actually has, we definitely want it to output
*something*, but the suggestion to indent was poor).

rust-lang/rust-clippy#12917

…s, r=oli-obk

Tighten `fn_decl_span` for async blocks

Tightens the span of `async {}` blocks in diagnostics, and subsequently async closures and async fns, by actually setting the `fn_decl_span` correctly. This is kinda a follow-up on rust-lang#125078, but it fixes the problem in a more general way.

I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters.

r? ````@estebank```` or ````@oli-obk```` or someone else on wg-diag or compiler i dont really care lol

…ishearth

doc_lazy_continuation: blank comment line for gap

This change addresses cases where doc comments are separated by blank lines, comments, or non-doc-comment attributes, like this:

```rust
/// - first line
// not part of doc comment
/// second line
```

Before this commit, Clippy gave a pedantically-correct warning about how you needed to indent the second line. This is unlikely to be what the user intends, and has been described as a "false positive." Since Clippy is warning you about a highly unintuitive behavior [that Rustdoc actually has](https://notriddle.com/rustdoc-html-demo-11/lazy-continuation-bad/test_dingus_2024/constant.D.html), we definitely want it to output *something*, but the suggestion to indent was poor.

Fixes rust-lang#12917

```
changelog: [`doc_lazy_continuation`]: suggest blank line for likely-unintended lazy continuations
```

…, r=Jarcho

Add error message to manual_inspect lint

r? `@Jarcho`

changelog: none

Rename `super_predicates_of` and similar queries to `explicit_*` to note that they're not elaborated

Rename:
* `super_predicates_of` -> `explicit_super_predicates_of`
* `implied_predicates_of` -> `explicit_implied_predicates_of`
* `supertraits_containing_assoc_item` -> `explicit_supertraits_containing_assoc_item`

This makes it clearer that, unlike (for example) [`TyCtxt::super_traits_of`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.super_traits_of), we don't automatically elaborate this set of predicates.

r? ``@lcnr`` or ``@oli-obk`` or someone from t-types idc

…ring, r=oli-obk

Implement new effects desugaring

cc `@rust-lang/project-const-traits.` Will write down notes once I have finished.

* [x] See if we want `T: Tr` to desugar into `T: Tr, T::Effects: Compat<true>`
* [x] Fix ICEs on `type Assoc: ~const Tr` and `type Assoc<T: ~const Tr>`
* [ ] add types and traits to minicore test
* [ ] update rustc-dev-guide

Fixes rust-lang#119717
Fixes rust-lang#123664
Fixes rust-lang#124857
Fixes rust-lang#126148

…ate_right

fix wrong msrv import in `new_lint` template

changelog: none

Although `manual_inspect`'s PR started some months ago, the lint is only
available in the current nightly (1.81.0), rather than 1.78.0.

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

Implement a lint to replace manual bit rotations with rotate_left/rot…

Fixes rust-lang#6861

r? `@llogiq`

---

changelog: add [`manual_rotate`] lint

`manual_inspect`: fix `clippy::version` from 1.78.0 to 1.81.0

Although `manual_inspect`'s PR started some months ago, the lint is only available in the current nightly (1.81.0), rather than 1.78.0.

```
changelog: [`manual_inspect`]: fix `clippy::version` from 1.78.0 to 1.81.0
```

…k_example, r=Manishearth

Fix doc for INEFFECTIVE_BIT_MASK and VERBOSE_BIT_MASK

Minor fixes for doc for INEFFECTIVE_BIT_MASK and VERBOSE_BIT_MASK

changelog: [none]

Image-related valid idents

False positives for idents in markdown

changelog: Add "WebP", "OpenExr", "YcbCr", "sRGB" to `doc-valid-idents` default.

Don't lint `assertions_on_constants` on any const assertions

close rust-lang#12816
close rust-lang#12847
cc rust-lang#12817

----

changelog: Fix false positives in consts for `assertions_on_constants` and `unnecessary_operation`.

…s not within the first `impl` block

build: Skip installing rust-docs with minimal rustup profile

r? `@flip1995`

changelog: none

Fix rust-lang#12964 - false positive with `into_iter_without_iter`

changelog: FP: `into_iter_without_iter`: No longer lints when the `iter` or `iter_mut` implementation is not within the first `impl` block

fixes rust-lang#12964

---

I'm pretty new to this open-source thing, so hopefully I did everything right. Got a little annoyed this false positive was happening in my code and the issue was inactive for two weeks so I thought I'd fix it myself.

As an aside, maybe `iter.map(...).next()` could be linted against? I don't see that ever being preferred over `iter.next().map(...)`, and it could've prevented the bug here.

Until now, the lint only emitted a warning, when breaking public API. Now it
doesn't lint at all when the config value is not set to `false`, bringing it in
line with the other lints using this config value.

Also ensures that this config value is documented in the lint.

Add explanatory comment to complex bounds check

Format

…backslash, r=blyxyas

doc_markdown: detect escaped `` ` `` when checking unmatched

```
changelog: [`doc_markdown`]: correctly detect backslash-escaped `` ` ``
```

…-api, r=xFrednet

Honor `avoid-breaking-exported-api` in `needless_pass_by_ref_mut`

Until now, the lint only emitted a warning, when breaking public API. Now it doesn't lint at all when the config value is not set to `false`, bringing it in line with the other lints using this config value.

Also ensures that this config value is documented in the lint.

changelog: none
(I don't think a changelog is necessary, since this lint is in `nursery`)

---

Fixes rust-lang/rust-clippy#11374

cc `@GuillaumeGomez`

Marking as draft: Does this lint even break public API? If I change a function signature from `fn foo(x: &mut T)` to `fn foo(x: &T)`, I can still call it with `foo(&mut x)`. The only "breaking" thing is that the `clippy::unnecessary_mut_passed` lint will complain that `&mut` at the callsite is not necessary, possibly trickling down to the crate user having to remote a `mut` from a variable. [Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=058165a7663902e84af1d23e35c10d66).

Are there examples where this actually breaks public API, that I'm missing?

…=lcnr

Re-implement a type-size based limit

r? lcnr

This PR reintroduces the type length limit added in rust-lang#37789, which was accidentally made practically useless by the caching changes to `Ty::walk` in rust-lang#72412, which caused the `walk` function to no longer walk over identical elements.

Hitting this length limit is not fatal unless we are in codegen -- so it shouldn't affect passes like the mir inliner which creates potentially very large types (which we observed, for example, when the new trait solver compiles `itertools` in `--release` mode).

This also increases the type length limit from `1048576 == 2 ** 20` to `2 ** 24`, which covers all of the code that can be reached with craterbot-check. Individual crates can increase the length limit further if desired.

Perf regression is mild and I think we should accept it -- reinstating this limit is important for the new trait solver and to make sure we don't accidentally hit more type-size related regressions in the future.

Fixes rust-lang#125460

…ednet

Fix some false-positive cases of `explicit_auto_deref`

changelog: [`explicit_auto_deref`] Fix some false-positive cases

Fix part of rust-lang#9841
Fix  rust-lang#12969

r? xFrednet

`needless_return`: Support `#[expect]` on the return statement

A fix for rust-lang/rust-clippy#9361 suppresses `clippy::needless_return` if there are any attributes on the `return` statement. This leads to some unexpected behavior, as described in rust-lang/rust-clippy#12998, where adding `#[expect(clippy::needless_return)]` suppresses the lint, but doesn't fulfill the expectation.

I now decided to manually fulfill any expectations, if they are before the attribute check.

---

Closes: rust-lang/rust-clippy#12998

changelog: none

….11, r=GuillaumeGomez

rustdoc: update to pulldown-cmark 0.11

r? rustdoc

This pull request updates rustdoc to the latest version of pulldown-cmark. Along with adding new markdown extensions (which this PR doesn't enable), the new pulldown-cmark version also fixes a large number of bugs. Because all text files successfully parse as markdown, these bugfixes change the output, which can break people's existing docs.

A crater run, rust-lang#121659, has already been run for this change.

The first commit upgrades and fixes rustdoc. The second commit adds a lint for the footnote and block quote parser changes, which break the largest numbers of docs in the Crater run. The strikethrough change was mitigated in pulldown-cmark itself.

Unblocks rust-lang/rust-clippy#12876

Do not leave a `+ ` line with only whitespace. In reality, the user will want to remove the entire line.

Add new lint `hashset_insert_after_contains`

This PR closes rust-lang/rust-clippy#11103.

This is my first PR creating a new lint (and the second attempt of creating this PR, the first one I was not able to continue because of personal reasons). Thanks for the patience :)

The idea of the lint is to find insert in hashmanps inside if staments that are checking if the hashmap contains the same value that is being inserted. This is not necessary since you could simply call the insert and check for the bool returned if you still need the if statement.

changelog: new lint: [hashset_insert_after_contains]

…es `const_extern_fn` feature

This patch adds a new lint that checks for potentially harder to read
byte char slices: `&[b'a', b'b']` and suggests to replace them with the
easier to read `b"ab"` form.

Signed-Off-By: Marcel Müller <m.mueller@ifm.com>
Co-authored-by: Matthias Beyer <matthias.beyer@ifm.com>

Use iterator to skip validation

Signed-off-by: Marcel Müller <m.mueller@ifm.com>
Suggested-by: Alex Macleod <alex@macleod.io>

Convert quote escapes to proper form

Signed-off-by: Marcel Müller <m.mueller@ifm.com>

Add more convertable test cases

Signed-off-by: Marcel Müller <m.mueller@ifm.com>

…_lint, r=Manishearth

Add new lint for byte char slices

This patch adds a new lint that checks for potentially harder to read byte char slices: `&[b'a', b'b']` and suggests to replace them with the easier to read `b"ab"` form.

Fixes rust-lang#10147

---

changelog: new lint: [`byte_char_slices`]
[rust-lang#10155](rust-lang/rust-clippy#10155)
<!-- changelog_checked -->

Tweak some structured suggestions to be more verbose and accurate

Addressing some issues I found while working on rust-lang#127282.
```
error: this URL is not a hyperlink
  --> $DIR/auxiliary/include-str-bare-urls.md:1:11
   |
LL | HEADS UP! https://example.com MUST SHOW UP IN THE STDERR FILE!
   |           ^^^^^^^^^^^^^^^^^^^
   |
   = note: bare URLs are not automatically turned into clickable links
note: the lint level is defined here
  --> $DIR/include-str-bare-urls.rs:14:9
   |
LL | #![deny(rustdoc::bare_urls)]
   |         ^^^^^^^^^^^^^^^^^^
help: use an automatic link instead
   |
LL | HEADS UP! <https://example.com> MUST SHOW UP IN THE STDERR FILE!
   |           +                   +
```
```
error[E0384]: cannot assign twice to immutable variable `v`
  --> $DIR/assign-imm-local-twice.rs:7:5
   |
LL |     v = 1;
   |     ----- first assignment to `v`
LL |     println!("v={}", v);
LL |     v = 2;
   |     ^^^^^ cannot assign twice to immutable variable
   |
help: consider making this binding mutable
   |
LL |     let mut v: isize;
   |         +++
```
```
error[E0393]: the type parameter `Rhs` must be explicitly specified
  --> $DIR/issue-22560.rs:9:23
   |
LL | trait Sub<Rhs=Self> {
   | ------------------- type parameter `Rhs` must be specified for this
...
LL | type Test = dyn Add + Sub;
   |                       ^^^
   |
   = note: because of the default `Self` reference, type parameters must be specified on object types
help: set the type parameter to the desired type
   |
LL | type Test = dyn Add + Sub<Rhs>;
   |                          +++++
```
```
error[E0596]: cannot borrow `v` as mutable, as it is not declared as mutable
  --> $DIR/issue-33819.rs:4:34
   |
LL |         Some(ref v) => { let a = &mut v; },
   |                                  ^^^^^^ cannot borrow as mutable
   |
help: try removing `&mut` here
   |
LL -         Some(ref v) => { let a = &mut v; },
LL +         Some(ref v) => { let a = v; },
   |
```
```
help: remove the invocation before committing it to a version control system
   |
LL -     dbg!();
   |
```
```
error[E0308]: mismatched types
  --> $DIR/issue-39974.rs:1:21
   |
LL | const LENGTH: f64 = 2;
   |                     ^ expected `f64`, found integer
   |
help: use a float literal
   |
LL | const LENGTH: f64 = 2.0;
   |                      ++
```
```
error[E0529]: expected an array or slice, found `Vec<i32>`
  --> $DIR/match-ergonomics.rs:8:9
   |
LL |         [&v] => {},
   |         ^^^^ pattern cannot match with input type `Vec<i32>`
   |
help: consider slicing here
   |
LL |     match x[..] {
   |            ++++
```
```
error[E0609]: no field `0` on type `[u32; 1]`
  --> $DIR/parenthesized-deref-suggestion.rs:10:21
   |
LL |     (x as [u32; 1]).0;
   |                     ^ unknown field
   |
help: instead of using tuple indexing, use array indexing
   |
LL |     (x as [u32; 1])[0];
   |                    ~ +
```

[`missing_const_for_fn`]: fix suggestions for fn with abi that requires `const_extern_fn` feature

closes: rust-lang#13008

---

changelog: [`missing_const_for_fn`]: fix suggestions for fn with abi that requires `const_extern_fn` feature.

* Merge some code paths
* Use `find` instead of a loop
* Move macro check to after hir pattern matching

* Check hir structure before macro checks
* Simplify constant checking

…archo

[`unnecessary_to_owned`]: catch `to_owned` on byte slice to create temporary `&str`

Closes rust-lang#11648

Detects the pattern `&String::from_utf8(bytes.to_vec()).unwrap()` and suggests `core::str::from_utf8(bytes).unwrap()`, which avoids the unnecessary intermediate allocation.

I decided to put this in the existing `unnecessary_to_owned` lint (rather than creating a new lint) for a few reasons:
- we get to use some of its logic (for example, recognizing any of the functions in the `to_owned` family, e.g. `to_vec`)
- the actual inefficient operation that can be avoided here is the call to `.to_vec()`, so this is in a way similar to the other cases caught by `unnecessary_to_owned`, just through a bunch of type conversions
- we can make this more "generic" later and catch other cases, so imo it's best not to tie this lint specifically to the `String` type

changelog: [`unnecessary_to_owned`]: catch `&String::from_utf8(bytes.to_vec()).unwrap()` and suggest `core::str::from_utf8(bytes).unwrap()`

* Simplify `def_id` extraction.
* Use the span of the method name instead of the call.

Refactor `disallowed_script_idents`

Minor change to use `find_map` instead of a loop. Not important, but it's easier to read.

changelog: none

Remove `is_in_test_module_or_function`

Uses are replaced with `is_in_test` for consistency with other lints and to simplify the implementation of the lints. This means the module name is no longer checked, but that was a horrible hack from a time when late passes couldn't see `#[cfg(..)]` attributes.

changelog: none

feat: add cfg_not_test lint

<!--
- \[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`
- \[ ] Added lint documentation
- \[x] Run `cargo dev fmt`

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

Fixes rust-lang#11234

changelog: new lint: [`cfg_not_test`]

I don't know whether to lint only the `attr` or also the item associated to it. I guess this would mean putting the check in another place than `check_attribute` but I can't find a way to get the associated item to the attribute.

Also, I'm not sure how to document this lint, I feel like my explications are bad.

…r_thread_local

…tializer_can_be_made_const, r=Alexendoo

Rename thread_local_initializer_can_be_made_const to missing_const_for_thread_local

Close rust-lang#12934
As discussed at rust-lang#12934 name `thread_local_initializer_can_be_made_const` sounds against convention for other lints which describe the issue/wrong code but not suggestion and it is quite long. The new name take example from existing lint `missing_const_for_fn`

changelog: `thread_local_initializer_can_be_made_const` : Rename to [`missing_const_for_thread_local`]

…ived`. Only check for the attribute on an impl block.

Only check for `automatically_derived` on impl blocks

This brings us in line with how rustc checks for the attribute. Also note that `unused_attributes` will trigger if it's placed anywhere else.

See:
https://github.com/rust-lang/rust/blob/9a21ac8e7efe9ea26a8065d0959a976ca32039bb/compiler/rustc_passes/src/dead.rs#L400-L403
https://github.com/rust-lang/rust/blob/9a21ac8e7efe9ea26a8065d0959a976ca32039bb/compiler/rustc_passes/src/liveness.rs#L143-L148

changelog: none

Clarify that `modulo_one` only applies to ints

changelog: [`modulo_one`]: (docs) Clarify that it only applies to integers

This might be nitpicky, but it's more technically correct.

It also helps if a user skims through the docs, because they may believe it also applies to `{float}`s. This doc edit minimizes that possibility

Refactor `disallowed_methods` and narrow span

Using the span of the call site just produces noisy diagnostics for long calls. Especially multi-line calls.

changelog: none

…Alexendoo

Lintcheck: Add `--warn-all` and make it the CI default

This PR adds a new `--warn-all` flag to lintcheck. This is intended for our CI, as it currently doesn't detect changes of `nursery` and `restriction` lints.

I only made it the default for the CI, as `restriction` lints tend to generate A LOT of lint triggers. Looking at you [`clippy::implicit_return`](https://rust-lang.github.io/rust-clippy/master/index.html#/clippy::implicit_return)

That's it. Should hopefully be easy to review.

Also, a bit thanks again to `@Alexendoo` for adding this to our CI ❤️

---

r? `@Alexendoo`

changelog: none