fix bug for large_enum_variants
Fix the discussion problem in the issue of https://github.com/rust-lang/rust-clippy/issues/7666#issuecomment-919654291
About the false positive problem of case:
```rust
enum LargeEnum6 {
A,
B([u8;255]),
C([u8;200]),
}
```
changelog: Fix largest_enum_variant wrongly identifying the second largest variant.
Rustup
This needs a review this time. Especially 521bf8f0fa cc `@camsteffen` I think this is necessary now, because `itertools` is no longer a dependency of `clippy_utils` and therefore this path can't be found 🤔
( I forgot about the sync last week. I should get to document this process better, so other people can do it when I'm not around )
changelog: none
bump clippy crates to edition 2021
Also helps with dogfooding edition 2021 a bit. :)
Tests passed locally.
---
changelog: bump edition from 2018 to 2021
Demote float_cmp to pedantic
See this issue: https://github.com/rust-lang/rust-clippy/issues/7666
This is one of the most frequently suppressed lints. It is deny-by-default. It is not actually clearly wrong, as there are many instances where direct float comparison is actually desirable. It is only after operating on floats that they may lose precision, and that depends greatly on the operation. As most correctness lints have a much higher standard of error, being based on hard and fast binary logic, this should not be amongst them.
A linter is not a substitute for observing the math carefully and running tests, and doing the desirable thing is even more likely to lead one to want exact comparisons.
changelog: Demote [`float_cmp`] from correctness to pedantic lints
Be explicit about using Binder::dummy
This is somewhat of a late followup to the binder refactor PR. It removes `ToPredicate` and `ToPolyTraitImpls` that hide the use of `Binder::dummy`. While this does make code a bit more verbose, it allows us be more careful about where we create binders.
Another alternative here might be to add a new trait `ToBinder` or something with a `dummy()` fn. Which could still allow grepping but allows doing something like `trait_ref.dummy()` (but I also wonder if longer-term, it would be better to be even more explicit with a `bind_with_vars(ty::List::empty())` *but* that's not clear yet.
r? ``@nikomatsakis``
Don't lint `suspicious_else_formatting` inside proc-macros
fixes: #7650
I'll add a test for this one soon.
changelog: Don't lint `suspicious_else_formatting` inside proc-macros
Expand box_vec lint to box_collection
fixed#7451
changelog: Expand `box_vec` into [`box_collection`], and have it error on all sorts of boxed collections
Change `while_let_on_iterator` suggestion to use `by_ref()`
It came up in the discussion #7659 that suggesting `iter.by_ref()` is a clearer suggestion than `&mut iter`. I personally think they're equivalent, but if `by_ref()` is clearer to people then that should be the suggestion.
changelog: Change `while_let_on_iterator` suggestion when using `&mut` to use `by_ref()`
New lint: `same_name_method`
changelog: ``[`same_name_method`]``
fix: https://github.com/rust-lang/rust-clippy/issues/7632
It only compares a method in `impl` with another in `impl trait for`
It doesn't lint two methods in two traits.
I'm not sure my approach is the best way. I meet difficulty in other approaches.
