Make the epsilon note spanless

Split check_fn function

Indicate when arrays are compared in error message

Make epsilon note spanless when comparing arrays

Add float cmp const tests for arrays

Add float cmp tests for arrays

Handle constant arrays with single value

Don't show comparison suggestion for arrays

Allow for const arrays of zeros

Handle evaluating constant index expression

Add handling of float arrays to miri_to_const

Update stderr of float_cmp test

Update field names in is_float

Add tests for float in array comparison

Add lint when comparing floats in an array

Finishes #4277

Auto merge of #5411 - dtolnay:hasher, r=flip1995

Downgrade implicit_hasher to pedantic

From the [documentation](https://rust-lang.github.io/rust-clippy/master/index.html#implicit_hasher), this lint is intended to suggest:

```diff
- pub fn foo(map: &mut HashMap<i32, i32>) { }

+ pub fn foo<S: BuildHasher>(map: &mut HashMap<i32, i32, S>) { }
```

I think this is pedantic. I get that this lint can benefit core libraries like serde, but that's exactly the use case for pedantic lints; a library like serde will [enable clippy_pedantic](https://github.com/serde-rs/json/blob/fd6741f4b0b3fc90a58a6f578e33a9adc6403f3f/src/lib.rs#L304) and take the time to go through everything possible. Similar for libraries doing a libz blitz style checkup before committing to a 1.0 release; it would make sense to run through all the available pedantic lints then.

But otherwise, for most codebases and certainly for industrial codebases, the above suggested change just makes the codebase more obtuse for questionable benefit.

changelog: Remove implicit_hasher from default set of enabled lints

Auto merge of #5437 - rabisg0:should-impl-trait, r=flip1995

Check fn header along with decl when suggesting to implement trait

When checking for functions that are potential candidates for trait
implementations check the function header to make sure modifiers like
asyncness, constness and safety match before triggering the lint.

Fixes #5413, #4290

changelog: check fn header along with decl for should_implement_trait

Auto merge of #5428 - dtolnay:cognitive, r=flip1995

Move cognitive_complexity to nursery

As discussed in https://github.com/rust-lang/rust-clippy/issues/5418#issuecomment-610054361; Clippy's current understanding of cognitive complexity is not good enough yet at analyzing code for understandability to have this lint be enabled by default.

changelog: Remove cognitive_complexity from default set of enabled lints

Check fn header along with decl when suggesting to implement trait

When checking for functions that are potential candidates for trait
implementations check the function header to make sure modifiers like
asyncness, constness and safety match before triggering the lint.

Fixes #5413, #4290

Downgrade implicit_hasher to pedantic

Move cognitive_complexity to nursery

Auto merge of #5438 - flip1995:rollup-pi762oy, r=flip1995

Rollup of 11 pull requests

Successful merges:

 - #5406 (Fix update_lints)
 - #5409 (Downgrade let_unit_value to pedantic)
 - #5410 (Downgrade trivially_copy_pass_by_ref to pedantic)
 - #5412 (Downgrade inefficient_to_string to pedantic)
 - #5415 (Add new lint for `Result<T, E>.map_or(None, Some(T))`)
 - #5417 (Update doc links and mentioned names in docs)
 - #5419 (Downgrade unreadable_literal to pedantic)
 - #5420 (Downgrade new_ret_no_self to pedantic)
 - #5422 (CONTRIBUTING.md: fix broken triage link)
 - #5424 (Incorrect suspicious_op_assign_impl)
 - #5425 (Ehance opt_as_ref_deref lint.)

Failed merges:

 - #5345 (Add lint for float in array comparison)
 - #5411 (Downgrade implicit_hasher to pedantic)
 - #5428 (Move cognitive_complexity to nursery)

r? @ghost

changelog: rollup

Run fmt and update test

Rollup merge of #5425 - xiongmao86:issue5367, r=flip1995

Ehance opt_as_ref_deref lint.

- [x] Added passing UI tests (including committed `.stderr` file)
- [x] `cargo test` passes locally
- [x] Run `cargo dev fmt`

Lint on opt.as_ref().map(|x| &**x). Fixes #5367.

changelog: lint on opt.as_ref().map(|x| &**x)

Rollup merge of #5424 - jpospychala:suspicious_op_assign_impl, r=flip1995

Incorrect suspicious_op_assign_impl

fixes #5255

changelog: In suspicious_op_assign_impl ignore all operators in expression if it's part of AssignOp

Rollup merge of #5422 - nickrtorres:contributing-triage, r=flip1995

CONTRIBUTING.md: fix broken triage link

Fixes #5421

Rollup merge of #5420 - dtolnay:newret, r=flip1995

Downgrade new_ret_no_self to pedantic

As motivated by #5418. This is the second most widely suppressed Clippy style lint, and [this grep.app search](https://grep.app/search?q=%5C%5Ballow%5C%28.%2Aclippy%3A%3Anew_ret_no_self%5Cb&regexp=true&case=true&filter[lang][0]=Rust) shows a large number of diverse reasonable signatures for a `new` method.

changelog: Remove new_ret_no_self from default set of enabled lints

Rollup merge of #5419 - dtolnay:unreadable, r=flip1995

Downgrade unreadable_literal to pedantic

As motivated by #5418. This is the top most commonly suppressed Clippy style lint, which indicates that the community has decided they don't share Clippy's opinion on the best style of this.

I've left the lint in as pedantic, though it could be that "restriction" would be better -- I can see this lint being useful as an opt-in restriction in some codebases.

changelog: Remove unreadable_literal from default set of enabled lints

Rollup merge of #5417 - flip1995:doc_update, r=flip1995

Update doc links and mentioned names in docs

changelog: none

Rollup merge of #5415 - nickrtorres:master, r=flip1995

Add new lint for `Result<T, E>.map_or(None, Some(T))`

Fixes #5414

PR Checklist
---
- [x] Followed lint naming conventions (the name is a bit awkward, but it seems to conform)
- [x] Added passing UI tests (including committed .stderr file)
- [x] cargo test passes locally
- [x] Executed cargo dev update_lints
- [x] Added lint documentation
- [x] Run cargo dev fmt

`Result<T, E>` has an [`ok()`](https://doc.rust-lang.org/std/result/enum.Result.html#method.ok) method that adapts a `Result<T,E>` into an `Option<T>`.
It's possible to get around this adapter by writing `Result<T,E>.map_or(None, Some)`.

This lint is implemented as a new variant of the existing [`option_map_none` lint](https://github.com/rust-lang/rust-clippy/pull/2128)

Rollup merge of #5412 - dtolnay:tostring, r=flip1995

Downgrade inefficient_to_string to pedantic

From the [documentation](https://rust-lang.github.io/rust-clippy/master/index.html#inefficient_to_string):

> ```diff
> - ["foo", "bar"].iter().map(|s| s.to_string());
>
> + ["foo", "bar"].iter().map(|&s| s.to_string());
> ```

I feel like saving 10 nanoseconds from the formatting machinery isn't worth asking the programmer to insert extra `&` / `*` noise in the *vast* majority of cases. This is a pedantic lint.

changelog: Remove inefficient_to_string from default set of enabled lints

Rollup merge of #5410 - dtolnay:trivially, r=flip1995

Downgrade trivially_copy_pass_by_ref to pedantic

The rationale for this lint is documented as:

> In many calling conventions instances of structs will be passed through registers if they fit into two or less general purpose registers.

I think the purported performance benefits of clippy's recommendation are overstated. This isn't worth asking people to sprinkle code with more `*`​`*`​`&`​`*`​`&` to chase the alleged performance.

This should be a pedantic lint that is disabled by default and opted in if some specific performance sensitive codebase determines that it is worthwhile.

As a reminder, a typical place that a reference to a primitive would come up is if the function is used as a filter. Triggering a performance-oriented lint on this type of code is the definition of pedantic.

```rust
fn filter(_n: &i32) -> bool {
    true
}

fn main() {
    let v = vec![1, 2, 3];
    v.iter().copied().filter(filter).for_each(drop);
}
```

```console
warning: this argument (4 byte) is passed by reference, but would be more efficient if passed by value (limit: 8 byte)
 --> src/main.rs:1:15
  |
1 | fn filter(_n: &i32) -> bool {
  |               ^^^^ help: consider passing by value instead: `i32`
```

changelog: Remove trivially_copy_pass_by_ref from default set of enabled lints

Rollup merge of #5409 - dtolnay:letunit, r=flip1995

Downgrade let_unit_value to pedantic

Given that the false positive in #1502 is marked E-hard and I don't have much hope of it getting fixed, I think it would be wise to disable this lint by default. I have had to suppress this lint in every substantial codebase (\>100k line) I have worked in. Any time this lint is being triggered, it's always the false positive case.

The motivation for this lint is documented as:

> A unit value cannot usefully be used anywhere. So binding one is kind of pointless.

with this example:

> ```rust
> let x = {
>     1;
> };
> ```

Sure, but the author would find this out via an unused_variable warning or from `x` not being the type that they need further down. If there ends up being a type error on `x`, clippy's advice isn't going to help get the code compiling because it can only run if the code already compiles.

changelog: Remove let_unit_value from default set of enabled lints

Rollup merge of #5406 - flip1995:update_lints_fix, r=flip1995

Fix update_lints

This fixes a bug in update_lints, where `internal` lints were not registered properly. This also cleans up some code. For example: The code generation functions no longer filter the lints the are given. This is now the task of the caller. This way, it is more obvious in the `replace_in_file` calls which lints will be included in which part of a file.

This also turns the lint modules private. There is no need for them to be public, since shared code should be in the utils module anyway.

And last but not least, this fixes the `register_lints` code generation, so also internal lints get registered.

changelog: none

Auto merge of #5429 - faern:use-assoc-int-float-consts, r=flip1995

Use assoc int and float consts instead of module level ones

changelog: Recommend primitive type associated constants instead of module level constants

In Rust 1.43 integer and float primitive types will have a number of new associated constants. For example `MAX`, `MIN` and a number of constants related to the machine representation of floats. https://github.com/rust-lang/rust/pull/68952

These new constants are preferred over the module level constants in `{core,std}::{f*, u*, i*}`. I have in the last few days made sure that the documentation in the main rust repository uses the new constants in every place I could find (https://github.com/rust-lang/rust/pull/69860, https://github.com/rust-lang/rust/pull/70782). So the next step is naturally to make the linter recommend the new constants as well.

This PR only changes two lints. There are more. But I did not want the PR to be too big. And since I have not contributed to clippy before it felt saner to start with a small PR so I see if there are any quirks. More will come later.

Use int assoc consts in MANUAL_SATURATING_ARITHMETIC

Use int assoc consts in checked_conversions lint

Use primitive type assoc consts in more tests

Use integer assoc consts in more lint example code

Don't import primitive type modules

Use assoc const NAN for zero_div_zero lint

Fix float cmp to use assoc fxx::EPSILON

Fix NAN comparison lint to use assoc NAN

Merge pull request #5434 from eddyb/rustup

rustup: update for the new Ty::walk interface.

The first commit fixes a portability bug in `setup-toolchain.sh`, while the second rewrites the handling of "trait impl methods" in `use_self` - even if `Ty::walk` could've still been used, it was IMO a misuse.

This could also serve as a PSA: *please* use `hir_ty_to_ty` instead of trying to compare `hir::Ty`s between themselves or against semantic `Ty`s. Its "quasi-deprecation" is 3 years old and doesn't really mean anything, just that it's currently uncached and that we should eventually querify it (either for a single HIR node, or for all of the nodes in an entire definition).

---

changelog: none

Format clippy_lints/src/let_underscore.rs

rustup: update for the new Ty::walk interface.

use_self: switch to hir_ty_to_ty.

Only /usr/bin/env is portable in shebangs.

Refine lint message.

Lint on opt.as_ref().map(|x| &**x).

Include OpAssign in suspicious_op_assign_impl

result_map_or_into_option: fix syntax error in example

result_map_or_into: fix dogfood_clippy error => {h,l}int

CONTRIBUTING.md: fix broken triage link

result_map_or_into_option: fix `cargo dev fmt --check` errors

result_map_or_into_option: move arg checks into tuple assignment

result_map_or_into_option: add `opt.map_or(None, |_| Some(y))` test

result_map_or_into_option: destructure lint tuple or return early

result_map_or_into_option: add good and bad examples

result_map_or_into_option: explicitly note absence of known problems

Downgrade new_ret_no_self to pedantic

Downgrade unreadable_literal to pedantic

Update CONTRIBUTING.md

Rename rustc -> rustc_middle in doc links

result_map_or_into_option: add lint to catch manually adpating Result -> Option

Result<T, E> has an `ok()` method that adapts a Result<T,E> into an Option<T>.
It's possible to get around this adapter by writing Result<T,E>.map_or(None, Some).

This lint is implemented as a new variant of the existing
[`option_map_none` lint](https://github.com/rust-lang/rust-clippy/pull/2128)

Move matches test in matches module

Run update_lints

Make lint modules private

Don't filter lints in code generation functions

Build lint lists once and the reuse them to update files

Get rid of Lint::is_internal method

Clean up update_lints

Merge pull request #5407 from flip1995/rustup

Rustup to rust-lang/rust#70634

Downgrade inefficient_to_string to pedantic

Downgrade trivially_copy_pass_by_ref to pedantic

Downgrade let_unit_value to pedantic

Rustup to rust-lang/rust#70634

Auto merge of #5403 - farnz:patch-1, r=flip1995

Improve docs for option_option

Hint about using tri-state enums to replace legitimate uses of `Option<Option<_>>`

changelog: The docs for `option_option` now suggest using a tri-state enum

Update clippy_lints/src/types.rs

Co-Authored-By: Philipp Krones <hello@philkrones.com>

Update types.rs

Update types.rs

Improve docs for option_option

Hint about using tri-state enums to replace legitimate uses of `Option<Option<_>>`

Auto merge of #5349 - jpospychala:useless_rc, r=Manishearth

useless Rc<Rc<T>>, Rc<Box<T>>, Rc<&T>, Box<&T>

refers to  #2394

changelog: Add lints for Rc<Rc<T>> and Rc<Box<T>> and Rc<&T>, Box<&T>

this is based on top of another change #5310 so probably should go after that one.

useless Rc<Rc<T>>, Rc<Box<T>>, Rc<&T>, Box<&T>

Auto merge of #5402 - pmk21:allow-let-underscore-must-use, r=flip1995

Allow let_underscore_must_use to be ignored

changelog: none
Fixes #5366

Auto merge of #5401 - dtolnay:option, r=Manishearth

Downgrade option_option to pedantic

Based on a search of my work codebase (\>500k lines) for `Option<Option<`, it looks like a bunch of reasonable uses to me. The documented motivation for this lint is:

> an optional optional value is logically the same thing as an optional value but has an unneeded extra level of wrapping

which seems a bit bogus in practice. For example a typical usage would look like:

```rust
let mut host: Option<String> = None;
let mut port: Option<i32> = None;
let mut payload: Option<Option<String>> = None;

for each field {
    match field.name {
        "host" => host = Some(...),
        "port" => port = Some(...),
        "payload" => payload = Some(...), // can be null or string
        _ => return error,
    }
}

let host = host.ok_or(...)?;
let port = port.ok_or(...)?;
let payload = payload.ok_or(...)?;
do_thing(host, port, payload)
```

This lint seems to fit right in with the pedantic group; I don't think linting on occurrences of `Option<Option<T>>` by default is justified.

---

changelog: Remove option_option from default set of enabled lints

Allow let_underscore

Update option_option ui test

Test for ignoring let_underscore_must_use

Downgrade option_option to pedantic

Auto merge of #5400 - flip1995:rustup, r=Manishearth

Rustups

r? @Manishearth

changelog: none

Fix dogfood fallout

Rustup to rust-lang/rust#70632

Rustup to rust-lang/rust#70081

Rustup to rust-lang/rust#70627

Auto merge of #5398 - flip1995:deescalate, r=Manishearth

Stop updating the lint counter with every new lint

r? @Manishearth

This PR does two things:

1. Clean up the clippy_dev module a bit (first 3 commits; cc #5394 )
2. Make the counter in the README count in steps of 50 lints. Also use a `lazy_static` `Vec` for the lint list, so no counter is required there anymore.

changelog: none

Run update_lints

Don't use an exact lint counter anymore

Move update_lints logic to its own module

Make limit_stderr_length a subcommand