Also stabilizes saturating_int_assign_impl, rust-langgh-92354.

And also make pub fns const where the underlying saturating_*
fns became const in the meantime since the Saturating type was
created.

…ic parameter

…riddle,Manishearth,flip1995

Reuse rustdoc's doc comment handling in Clippy

Moves `source_span_for_markdown_range` and `span_of_attrs` (renamed to `span_of_fragments`) to `rustc_resolve::rustdoc` so it can be used in Clippy

Fixes rust-lang/rust-clippy#10277
Fixes rust-lang/rust-clippy#5593
Fixes rust-lang/rust-clippy#10263
Fixes rust-lang/rust-clippy#2581

new unnecessary_map_on_constructor lint

changelog: [`unnecessary_map_on_constructor`]: adds lint for cases in which map is not necessary. `Some(4).map(myfunction)` => `Some(myfunction(4))`

Closes rust-lang/rust-clippy#6472

Note that the case mentioned in the issue `Some(..).and_then(|..| Some(..))` is fixed by a chain of lint changes. This PR completes the last part of that chain.

By `bind_instead_of_map`[lint](https://rust-lang.github.io/rust-clippy/master/index.html#/bind_instead_of_map):
`Some(4).and_then(|x| Some(foo(4)))` => `Some(4).map(|x| foo)`

By `redundant_closure` [lint](https://rust-lang.github.io/rust-clippy/master/index.html#/redundant_closure):
`Some(4).map(|x| foo)` => `Some(4).map(fun)`

Finally by this PR `unnecessary_map_on_constructor`:
`Some(4).map(fun)` => `Some(fun(4))`

I'm not sure this is the desired behavior for clippy and if it should be addressed in another issue/PR. I'd be up to give it a try if that's the case.

…=dswij

Ignore span's parents in `collect_ast_format_args`/`find_format_args`

Fixes rust-lang#11470, covers some cases missed by rust-lang#10980

Can't have a test yet because of rust-lang#11126 but it works locally

changelog: none

r? `@dswij`

…_by_ref_mut`

It is the last thing depending on syn 1.0 in clippy

Update Clippy

r? `@Manishearth`

[`len_without_is_empty`]: follow type alias to find inherent `is_empty` method

Fixes rust-lang#11165

When we see an `impl B` and `B` is a type alias to some type `A`, then we need to follow the type alias to look for an `is_empty` method on the aliased type `A`. Before this PR, it'd get the inherent impls of `B`, which there aren't any and so it would warn that there isn't an `is_empty` method even if there was one.
Passing the type alias `DefId` to `TyCtxt::type_of` gives us the aliased `DefId` (or simply return the type itself if it wasn't a type alias) so we can just use that

changelog: [`len_without_is_empty`]: follow type alias to find inherent `is_empty` method

Remove `derive_new` test dependency

It is the last thing depending on syn 1.0 in clippy

changelog: none

This fixes the changes brought to codegen tests when effect params are
added to libcore, by not attempting to monomorphize functions that get
the host param by being `const fn`.

…-obk

treat host effect params as erased in codegen

This fixes the changes brought to codegen tests when effect params are added to libcore, by not attempting to monomorphize functions that get the host param by being `const fn`.

r? `@oli-obk`

…rimes, r=flip1995

Return a value from find_format_args instead of using a callback

r? `@flip1995`

changelog: none

…-naber

Improve invalid let expression handling

- Move all of the checks for valid let expression positions to parsing.
- Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location.
- Suppress some later errors and MIR construction for invalid let expressions.
- Fix a (drop) scope issue that was also responsible for rust-lang#104172.

Fixes rust-lang#104172
Fixes rust-lang#104868

also share the code that emits the actual error

…, r=Manishearth

Truncate files when opening in metadata-collector

Fixes the issue seen here rust-lang/rust-clippy#11483 (comment) and in a couple other PRs

The changelog file was opened without truncating it, so if the new version is shorter than the old one stray contents would remain at the end of the file

The other two files first removed the file so didn't have this problem, but in all cases we now use `fs::write`/`File::create` which is write + create + truncate

changelog: none

…dnet

Ignore closures for some type lints

Fixes rust-lang#11417

`hir_ty_to_ty` is used in a couple of the `!is_local` lints, which doesn't play nicely inside bodies

changelog: none

… r=flip1995

Ignore `#[doc(hidden)]` functions in clippy doc lints

Fixes rust-lang/rust-clippy#11501

The implementation before rust-lang#115689 had a check for unsugared doc comments that also happened to catch `#[doc(hidden)]`, this adds the check back in more explicitly

https://github.com/rust-lang/rust/blob/852bf4e51bf260550cd1a280d2146f1c0641b1e8/src/tools/clippy/clippy_lints/src/doc.rs#L526-L529

r? `@flip1995`

[`extra_unused_type_parameters`]: Fix edge case FP for parameters in where bounds

Generic parameters can end up being used on the left side of where-bounds if they are not directly bound but instead appear nested in some concrete generic type. Therefore, we should walk the left side of where bounds, but only if the bounded type is *not* a generic param, in which case we still need to ignore the bound.

Fixes rust-lang#11302

changelog: [`extra_unused_type_parameters`]: Fix edge case false positive for parameters in where bounds

fix filter_map_bool_then with a bool reference

changelog: [`filter_map_bool_then`]: Fix the incorrect autofix when the `bool` in question is a reference.

fix rust-lang#11503

new lint: `path_ends_with_ext`

Closes rust-lang#11479

Not sure if it needs more test cases. I couldn't come up with any other ones, but it is a pretty simple lint logic wise with not too many checks

changelog: new lint: [`path_ends_with_ext`]

[`useless_conversion`]: don't lint if type parameter has unsatisfiable bounds for `.into_iter()` receiver

Fixes rust-lang#11300.

Before this PR, clippy assumed that if it sees a `f(x.into_iter())` call and the type at that argument position is generic over any `IntoIterator`, then the `.into_iter()` call must be useless because `x` already implements `IntoIterator`, *however* this assumption is not right if the generic parameter has more than just the `IntoIterator` bound (because other traits can be implemented for the IntoIterator target type but not the IntoIterator implementor, as can be seen in the linked issue: `<[i32; 3] as IntoIterator>::IntoIter` satisfies `ExactSizeIterator`, but `[i32; 3]` does not).

So, this PR makes it check that the type parameter only has a single `IntoIterator` bound. It *might* be possible to check if the type of `x` in `f(x.into_iter())` satisfies all the bounds on the generic type parameter as defined on the function (which would allow removing the `.into_iter()` call even with multiple bounds), however I'm not sure how to do that, and the current fix should always work.

**Edit:** This PR has been changed to check if any of the bounds don't hold for the type of the `.into_iter()` receiver, so we can still lint in some cases.

changelog: [`useless_conversion`]: don't lint `.into_iter()` if type parameter has multiple bounds

trigger [`transmute_null_to_fn`] on chain of casts

fixes: rust-lang#11485

changelog: trigger [`transmute_null_to_fn`] on chain of casts

fix FP of let_unit_value on async fn args

changelog: [`let_unit_value`]: fix the FalsePostive on async fn arguments

fix rust-lang#11502

fix typo

Co-authored-by: Alejandra González <blyxyas@gmail.com>

Co-authored-by: Timo <30553356+y21@users.noreply.github.com>

add extra `byref` checking for the guard's local

changelog: [`redundant_guards`]: Now checks if the variable is bound using `ref` before linting.

The lint should not be emitted, when the local variable is bind by-ref in the pattern.

fixes rust-lang#11465

…=Jarcho

[`filter_map_bool_then`]: include multiple derefs from adjustments

In rust-lang#11506 this lint was improved to suggest one deref if the bool is behind references (fixed the FP rust-lang#11503), however it might need multiple dereferences if the bool is behind multiple layers of references or custom derefs. E.g. `&&&bool` needs `***b`.

changelog: [`filter_map_bool_then`]: suggest as many dereferences as there are needed to get to the bool

…=dtolnay

Stabilize the `Saturating` type

Closes rust-lang#87920
Closes rust-lang#92354

Stabilization report rust-lang#87920 (comment)
FCP rust-lang#87920 (comment)

Split `needless_borrow` into two lints

Splits off the case where the borrow is used as a generic argument to a function. I think the two cases are different  enough to warrant a separate lint.

The tests for the new lint have been reordered to group related parts together. Two warning have been dropped, one looked like it was testing the generic argument form, but it ends up triggering the auto-deref variant. The second was just a redundant test that didn't do anything interesting.

An issue with cycle detection is also included. The old version was checking if a cycle was reachable from a block when it should have been checking if the block is part or a cycle.

As a side note, I'm liking the style of just jamming all the tests into separate scopes in main.

changelog: Split off `needless_borrows_for_generic_args` from `needless_borrow`

This lint checks for `as_str` on a `String` immediately followed by `as_bytes` or `is_empty` as those methods are available on `String` too. This could possibly also be extended to `&[u8]` in the future.

…nt-levels, r=xFrednet

used_underscore_bindings: respect lint levels on the binding definition

Fixes rust-lang#11520
Fixes rust-lang#947

Also ignores usages of `PhantomData`

changelog: none

Update remark CI deps

[Remark v15](https://github.com/remarkjs/remark/releases/tag/15.0.0) was just released that needs a newer node version, this updates us to 18 (the current LTS)

Also updates mdbook while we're at it

changelog: none

…sync functions right besides other closures handling.

Add doc comment explaining what `MutablyUsedVariablesCtxt::prev_move_to_closure` is about.

fix ICE by `u64::try_from(<u128>)`

changelog: Fix the ICE in [`cast_possible_truncation`], when the `Shr` bits is larger than `u64::MAX`

fix rust-lang#11426

move required_consts check to general post-mono-check function

This factors some code that is common between the interpreter and the codegen backends into shared helper functions. Also as a side-effect the interpreter now uses the same `eval` functions as everyone else to get the evaluated MIR constants.

Also this is in preparation for another post-mono check that will be needed for (the current hackfix for) rust-lang#115709: ensuring that all locals are dynamically sized.

I didn't expect this to change diagnostics, but it's just cycle errors that change.

r? `@oli-obk`

Add redundant_as_str lint

This lint checks for `as_str` on a `String` immediately followed by `as_bytes` or `is_empty` as those methods are available on `String` too. This could possibly also be extended to `&[u8]` in the future.

changelog: New lint [`redundant_as_str`] rust-lang#11526

…lyxyas

Move zero_ptr to the casts module

Also a bit of a touch up to the code while I was there

changelog: none

this way we have mir::ConstValue and ty::ValTree as reasonably parallel

fix cast_lossless with macro call

changelog: fix [`cast_lossless`] in the case when the cast operand is a macro call

fix rust-lang#11458

This patch sets the two configuration options for
`undocumented_unsafe_blocks` to `true` by default: these are
`accept-comment-above-statement` and `accept-comment-above-attributes`.
Having these values `false` by default prevents what many users would
consider clean code, e.g. placing the `// SAFETY:` comment above a
single-line functino call, rather than directly next to the argument.

changelog: [`undocumented_unsafe_blocks`]: set
`accept-comment-above-statement` and `accept-comment-above-attributes`
to `true` by default.

…ure, r=Centri3

Fix mutaby used async function argument in closure for `needless_pass_by_ref_mut`

Fixes rust-lang/rust-clippy#11380.

The problem was that it needed to go through closures as well in async functions to correctly find the mutable usage of async function arguments.

changelog: Correctly handle mutable usage of async function arguments in closures.

r? `@Centri3`

…efaults, r=Centri3

Change defaults of `accept-comment-above-statement` and `accept-comment-above-attributes`

This patch sets the two configuration options for `undocumented_unsafe_blocks` to `true` by default: these are `accept-comment-above-statement` and `accept-comment-above-attributes`. Having these values `false` by default prevents what many users would consider clean code, e.g. placing the `// SAFETY:` comment above a single-line functino call, rather than directly next to the argument.

This was originally discussed in rust-lang/rust-clippy#11162

changelog: [`undocumented_unsafe_blocks`]: set
`accept-comment-above-statement` and `accept-comment-above-attributes` to `true` by default.

…fate

[`redundant_guards`]: lint if the pattern is on the left side

A tiny improvement to the `redundant_guards` lint. There's no associated issue for this, just noticed it while going through the code.
Right now it warns on `Some(x) if x == 2` and suggests `Some(2)`, but it didn't do that for `Some(x) if 2 == x` (i.e. when the local is on the right side and the pattern on the left side).

changelog: [`redundant_guards`]: also lint if the pattern is on the left side

rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const

Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`.

Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all.

However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish...

``@oli-obk`` any ideas?

fix FP with needless_raw_string_hashes

changelog: Fix [`needless_raw_string_hashes`]: Continue the lint checking of raw string when `needless_raw_strings` is allowed.

fix rust-lang#11420

Remove most usage of `hir_ty_to_ty`

Removes the usages where there's a suitable query or the type was already available elsewhere. The remaining cases would all require more involved changes

changelog: none

r? `@Jarcho`

…libcore, r=oli-obk

Enable effects for libcore

~~r? `@oli-obk~~`

forgot you are on vacation, oops

…txt method.