Fixes issue where ranges containing ints with different signs would be
incorrect due to comparing as unsigned.

Previously, the `cast_lossless` lint would issue a warning on code that
converted a `usize` value to `f64`, on 32-bit targets.

`usize` to `f64` is a lossless cast on 32-bit targets, however there is
no corresponding `f64::from` that takes a `usize`, so `cast_lossless`'s
suggested replacement does not compile.

This PR disables the lint in the case of casting from `usize` or `isize`.

Fixes rust-lang#3689.

changelog: [`cast_lossless`] no longer gives wrong suggestion on usize->f64

This reverts commit bb01aca.

Partial: Keep regression tests

Adds the missing line to cast-slice-different-sizes lint documentation
/closes 8781

Added missing `### What it does`

Adds the missing line to ``[`cast-slice-different-sizes`]`` lint documentation
fixes rust-lang#8781

changelog: none

…nger needed.

Lint `empty_lint_after_outer_attr` on argumentless macros

Reverts the change from 034c81b as it's no longer needed. The test is left just in case. Original issue is rust-lang#2475.

changelog: Lint `empty_lint_after_outer_attr` on argumentless macros again

Fix `cast_lossless` to avoid warning on `usize` to `f64` conversion.

Previously, the `cast_lossless` lint would issue a warning on code that
converted a `usize` value to `f64`, on 32-bit targets.

`usize` to `f64` is a lossless cast on 32-bit targets, however there is
no corresponding `f64::from` that takes a `usize`, so `cast_lossless`'s
suggested replacement does not compile.

This PR disables the lint in the case of casting from `usize` or `isize`.

Fixes rust-lang#3689.

changelog: [`cast_lossless`] no longer gives wrong suggestion on usize,isize->f64

-Zast-json is being removed shortly: rust-lang#85993.
ast-tree does essentially the same thing, and still works today even before that PR lands.

For check_range_bounds return type.

Suggest -Zunpretty=ast-tree instead of -Zast-json

-Zast-json is being removed shortly: rust-lang#85993.
ast-tree does essentially the same thing, and still works today even before that PR lands.

changelog: none

Support negative ints in manual_range_contains

fixes: rust-lang#8721
changelog: Fixes issue where ranges containing ints with different signs would be
incorrect due to comparing as unsigned.

Signed-off-by: Miguel Guarniz <[email protected]>

Pass through extra args in `cargo dev lint`

changelog: Pass through extra args in `cargo dev lint`

Lets you pass some useful flags through, like `-A/W/etc`, `--fix`, `--force-warn`

Allow inline consts to reference generic params

Tracking issue: rust-lang#76001

The RFC says that inline consts cannot reference to generic parameters (for now), same as array length expressions. And expresses that it's desirable for it to reference in-scope generics, when array length expressions gain that feature as well.

However it is possible to implement this for inline consts before doing this for all anon consts, because inline consts are only used as values and they won't be used in the type system. So we can have:
```rust
fn foo<T>() {
    let x = [4i32; std::mem::size_of::<T>()];   // NOT ALLOWED (for now)
    let x = const { std::mem::size_of::<T>() }; // ALLOWED with this PR!
    let x = [4i32; const { std::mem::size_of::<T>() }];   // NOT ALLOWED (for now)
}
```

This would make inline consts super useful for compile-time checks and assertions:
```rust
fn assert_zst<T>() {
    const { assert!(std::mem::size_of::<T>() == 0) };
}
```

This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary, but this is exactly what a "desugared" inline const would do:
```rust
fn assert_zst<T>() {
    struct F<T>(T);
    impl<T> F<T> {
        const V: () = assert!(std::mem::size_of::<T>() == 0);
    }
    let _ = F::<T>::V;
}
```

It should also be noted that the current inline const implementation can already reference the type params via type inference, so this resolver-level restriction is not any useful either:
```rust
fn foo<T>() -> usize {
    let (_, size): (PhantomData<T>, usize) = const {
        const fn my_size_of<T>() -> (PhantomData<T>, usize) {
            (PhantomData, std::mem::size_of::<T>())
        }
        my_size_of()
    };
    size
}
```

```@rustbot``` label: F-inline_const

…-rustc-typeck, r=cjgillot

Remove ItemLikeVisitor impls from rustc_typeck

Issue rust-lang#95004
cc `@cjgillot`

author Preston From <[email protected]> 1645164142 -0600
committer Preston From <[email protected]> 1650005351 -0600

Address `unnecessary_to_owned` false positive

My proposed fix for rust-lang#8759 is to revise the conditions that delineate `redundant_clone` and `unnecessary_to_owned`:
```rust
        // Only flag cases satisfying at least one of the following three conditions:
        // * the referent and receiver types are distinct
        // * the referent/receiver type is a copyable array
        // * the method is `Cow::into_owned`
        // This restriction is to ensure there is no overlap between `redundant_clone` and this
        // lint. It also avoids the following false positive:
        //  rust-lang/rust-clippy#8759
        //   Arrays are a bit of a corner case. Non-copyable arrays are handled by
        // `redundant_clone`, but copyable arrays are not.
```
This change causes a few cases that were previously flagged by `unnecessary_to_owned` to no longer be flagged. But one could argue those cases would be better handled by `redundant_clone`.

Closes rust-lang#8759

changelog: none

With rust-lang#93803 `impl Trait` function arguments get desugared to hidden
where bounds. However, Clippy needs to know if a bound was originally a
impl Trait or an actual bound. This adds a field to the
`WhereBoundPredicate` struct to keep track of this information during
HIR lowering.

Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions

A new clippy lint for issue 93883 (rust-lang#93883). Relies on a new trait in `marker` (called `SignificantDrop` to enable linting), which is why this PR is for the rust-lang repo and not the clippy repo.

changelog: new lint [`significant_drop_in_scrutinee`]

…cjgillot

Track if a where bound comes from a impl Trait desugar

With rust-lang#93803 `impl Trait` function arguments get desugared to hidden where bounds. However, Clippy needs to know if a bound was originally a `impl Trait` or an actual bound. This adds a field to the `WhereBoundPredicate` struct to keep track of this information during AST->HIR lowering.

r? `@cjgillot`

cc `@estebank` (as the reviewer of rust-lang#93803)

… r=llogiq

Optionally allow `expect` and `unwrap` in tests

This addresses rust-lang#1015, except it makes the new behavior optional.

The reason for the msrv-related changes is as follows.

Rather than expand `check_methods` list of arguments, it seemed easier to make `check_methods` a method of `Methods`, so that `check_methods` could access `Methods`' fields.

`check_methods` had an `msrv` parameter, which I consequently made a field of `Methods`. But, to avoid adding a lifetime parameter to `Methods`, I made the field type `Option<RustcVersion>` instead of the parameter's existing type, `Option<&RustcVersion>`. This seemed sensible since `RustcVersion` implements `Copy`. But this broke a lot of code that expected an `Option<&RustcVersion>` or `&Option<RustcVersion>`. I changed all of those occurrences to `Option<RustcVersion>`. IMHO, the code is better as a result of these changes, though.

The msrv-related changes are in their own commit to (hopefully) ease review.

Closes rust-lang#1015

changelog: optionally allow `expect` and `unwrap` in tests

r? `@llogiq`

…leywiser

Support tool lints with the `#[expect]` attribute (RFC 2383)

This PR fixes the ICE rust-lang#94953 by making the assert for converted expectation IDs conditional.

Additionally, it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way, I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints.

The number of changes comes from the long test file. This may look like a monster PR, this may smell like a monster PR and this may be a monster PR, but it's a harmless monster. 🦕

---

Closes: rust-lang#94953

cc: rust-lang#85549

r? `@wesleywiser`

cc: `@rust-lang/rustdoc`

Recommend let chains over if_chain in docs

Switches over bit_mask.rs to let chains in order to create a nice example

While the rustfmt thing isn't resolved yet, my rust-analyzer isn't a fan of large `if_chains!`s, it stops giving me hover info and such after some number of if statements

changelog: none

…lip1995

Replace `#[allow]` with `#[expect]` in Clippy

Hey `@rust-lang/clippy,` `@Alexendoo,` `@dswij,` I'm currently working on the expect attribute as defined in [Rust RFC 2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). With that, an `#[allow]` attribute can be replaced with a `#[expect]` attribute that suppresses the lint, but also emits a warning, if the lint isn't emitted in the expected scope.

With this PR I would like to test the attribute on a project scale and Clippy obviously came to mind. This PR replaces (almost) all `#[allow]` attributes in `clippy_utils` and `clippy_lints` with the `#[expect]` attribute. I was also able to remove some allows since, the related FPs have been fixed 🎉.

My question is now, are there any concerns regarding this? It's still okay to add normal `#[allow]` attributes, I see the need to nit-pick about that in new PRs, unless it's actually a FP. Also, I would not recommend using `#[expect]` in tests, as changes to a lint could the trigger the expect attribute in other files.

Additionally, I've noticed that Clippy has a bunch of `#[allow(clippy::too_many_lines)]` attributes. Should we maybe allow the lint all together or increase the threshold setting? To me, it seems like we mostly just ignore it in our code. 😅 🙃

---

changelog: none

r? `@flip1995` (I've requested you for now, since you're also helping with reviewing the expect implementation. You are welcome to delegate this PR, even if it should be a simple review 🙃 )

…r=xFrednet

Ignore unfulfilled_lint_expectations in metadata collection

r? `@xFrednet`

When metadata collection is enabled the regular early/late pass registrations are skipped, which the `#[expect()]`s were no fan of: https://github.com/rust-lang/rust-clippy/runs/6356675328?check_suite_focus=true

changelog: none

introduce rc_clone_in_vec_init lint

Closes rust-lang#8719

changelog: Introduce [`rc_clone_in_vec_init`] lint

New lint: [`derive_partial_eq_without_eq`]

Introduces a new lint, [`derive_partial_eq_without_eq`].

See: rust-lang#1781 (doesn't close it though).

changelog: add lint [`derive_partial_eq_without_eq`]

Follow up rust-lang#96861.

This PR uses the traits added to the Rust 2021 Edition prelude.

> The `TryInto`, `TryFrom` and `FromIterator` traits are now part of the prelude.

https://doc.rust-lang.org/edition-guide/rust-2021/prelude.html

Fix `match_single_binding` suggestion for assign expressions

changelog: Fix suggestion for assign expressions in [`match_single_binding`]
closes: rust-lang#8723

Use the traits added to the Rust 2021 Edition prelude

Follow up rust-lang#96861.

This PR uses the traits added to the Rust 2021 Edition prelude.

> The `TryInto`, `TryFrom` and `FromIterator` traits are now part of the prelude.

https://doc.rust-lang.org/edition-guide/rust-2021/prelude.html

---

changelog: none

don't encode only locally used attrs

Part of rust-lang/compiler-team#505.

We now filter builtin attributes before encoding them in the crate metadata in case they should only be used in the local crate. To prevent accidental misuse `get_attrs` now requires the caller to state which attribute they are interested in. For places where that isn't trivially possible, I've added a method `fn get_attrs_unchecked` which I intend to remove in a followup PR.

After this pull request landed, we can then slowly move all attributes to only be used in the local crate while being certain that we don't accidentally try to access them from extern crates.

cc rust-lang#94963 (comment)

Some lintcheck cleanup

A grab bag of smaller changes:

Panics if a crate source isn't valid, and fixes the `ryu` crate entry so it's picked up. Took me a while to realise why I couldn't do `cargo lintcheck --only ryu` 😅

Parses messages with `cargo_metadata`, this catches a few more lints that were ignored because the message had an [expansion field](https://docs.rs/cargo_metadata/latest/cargo_metadata/diagnostic/struct.DiagnosticSpanMacroExpansion.html) that contained a path pointing into `.../.toolchains/...`. It also no longer emits some log lines with `null` as the column

It also merges the `run_clippy_lint` invocations and splits `LintcheckConfig` out into its own file

changelog: none

This PR has implemented improved representation.

- Use "lib" instead of "lifb"
- Use "triggered" instead of "triggere"
- Use "blacklisted_name" instead of "blackisted_name"
- Use "stabilization" instead of "stabilisation"
- Use "behavior" instead of "behaviour"
- Use "target" instead of "tartet"
- Use "checked_add" instead of "chcked_add"
- Use "anti-pattern" instead of "antipattern"
- Use "suggestion" instead of "suggesttion"
- Use "example" instead of "exampel"
- Use "Cheat Sheet" instead of "Cheatsheet"

Tweak some words improved representation

Hello! Thank you for this awesome project!

This PR has implemented improved representation.

- Use "lib" instead of "lifb"
- Use "triggered" instead of "triggere"
- Use "blacklisted_name" instead of "blackisted_name"
- Use "stabilization" instead of "stabilisation"
- Use "behavior" instead of "behaviour"
- Use "target" instead of "tartet"
- Use "checked_add" instead of "chcked_add"
- Use "anti-pattern" instead of "antipattern"
- Use "suggestion" instead of "suggesttion"
- Use "example" instead of "exampel"
- Use "Cheat Sheet" instead of "Cheatsheet"

---

changelog: none

…r=Alexendoo

Fix redundant_allocation warning for Rc<Box<str>>

changelog: [`redundant_allocation`] Fixes rust-lang#8604

Fixes false positives where a fat pointer with `str` type was made thin by another allocation, but that thinning allocation was marked as redundant

Signed-off-by: Miguel Guarniz <[email protected]>

Add EarlyBinder

Chalk has no concept of `Param` (https://github.com/rust-lang/chalk/blob/e0ade19d139bc784384acc6736cd960c91dd55a1/chalk-ir/src/lib.rs#L579) or `ReEarlyBound` (https://github.com/rust-lang/chalk/blob/e0ade19d139bc784384acc6736cd960c91dd55a1/chalk-ir/src/lib.rs#L1308). Everything  is just "bound" - the equivalent of rustc's late-bound. It's not completely clear yet whether to move everything to the same time of binder in rustc or add `Param` and `ReEarlyBound` in Chalk.

Either way, tracking when we have or haven't already substituted out these in rustc can be helpful.

As a first step, I'm just adding a `EarlyBinder` newtype that is required to call `subst`. I also add a couple "transparent" `bound_*` wrappers around a couple query that are often immediately substituted.

r? `@nikomatsakis`

…Version`

Add `duplicate_mod` lint

Inspired by rust-lang#8827, warns if there's a single file that is loaded by more than one `mod` item

```rust,ignore
// lib.rs
mod a;
mod b;
```
```rust,ignore
// a.rs
#[path = "./b.rs"]
mod b;
```

It adds a `canonicalize` call per `mod file;` encountered, which I don't think should be too heavy

Integration tests with common modules, e.g. [`test_utils`](https://github.com/rust-lang/rust-clippy/tree/2038084cf2253b57cf8b405ab000a92b68346f43/tests/test_utils) doesn't trigger it as each test is compiled separately, however I couldn't figure out a good way to add a test for that

changelog: Add [`duplicate_mod`] lint

…archo

Rename `eval_order_dependence` to `mixed_read_write_expression`, move to nursery

As per the [reference](https://doc.rust-lang.org/1.51.0/reference/expressions.html#evaluation-order-of-operands) evaluation order is now defined.

I'm pretty sure rust always compiled with this evaluation order anyways so there's no reason the put an msrv limit on the lint.

changelog: Rename `eval_order_dependence` to `mixed_read_write_expression`, move to nursery

…j,xFrednet

Don't lint `vec_init_then_push` when further extended

fixes rust-lang#7071

This will still lint when a larger number of pushes are done (four currently). The exact number could be debated, but this is more readable then a sequence of pushes so it shouldn't be too large.

changelog: Don't lint `vec_init_then_push` when further extended.
changelog: Remove `mut` binding from `vec_init_then_push` when possible.

`undocumented_unsafe_blocks` does not trigger on unsafe trait impls

Closes rust-lang#8505

changelog: This lint checks unsafe impls NOT from macro expansions and checks ones in macro declarations.
~~`unsafe impl`s from macro invocations don't trigger the lint for now.~~
~~This lint checks unsafe impls from/not from macro expansions~~

Add version filtering option to the lint list

I'm no web dev, so I don't know if this is the best execution 😄.

Here's how it looks:

![Desktop](https://user-images.githubusercontent.com/69764315/165403602-9e39fe0f-6a96-46cb-ba51-8b035e74cce4.gif)

And on mobile:

![Mobile](https://user-images.githubusercontent.com/69764315/165403908-fc4a0051-2ed4-48a3-b45b-b261f49ce259.png)

I've split this into two commits, in the second one I moved the JS into its own file to make it easier to work on. Is that alright? And if so, could the same thing be done to the css?

changelog: none
cc: rust-lang#7958, `@repi`
r? `@xFrednet`

Fix ICE in `let_unit_value` when calling a static or const callable type

fixes rust-lang#8821

changelog: Fix ICE in `let_unit_value` when calling a static or const callable type

…vec-init, r=xFrednet

add suggestions to rc_clone_in_vec_init

A followup to rust-lang/rust-clippy#8769
I also switch the order of the 2 suggestions, since the loop initialization one is probably the common case.

`@xFrednet` I'm not letting you guys rest for a minute 😅
changelog: add suggestions to [`rc_clone_in_vec_init`]

…t, r=cjgillot

 Retire `ItemLikeVisitor` trait

Issue rust-lang#95004
cc `@cjgillot`