Auto merge of #104688 - flip1995:clippyup, r=Manishearth,flip1995

Update Clippy

r? `@Manishearth`

Sorry for taking so long. There were so many blockers and so little time. This situation should be mitigated with #104007 in the future.

1 files changed, 0 insertions, 41 deletions

diff --git a/src/docs/large_enum_variant.txt b/src/docs/large_enum_variant.txt
deleted file mode 100644
index 1f95430790d..00000000000
--- a/src/docs/large_enum_variant.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-### What it does
-Checks for large size differences between variants on
-`enum`s.
-
-### Why is this bad?
-Enum size is bounded by the largest variant. Having one
-large variant can penalize the memory layout of that enum.
-
-### Known problems
-This lint obviously cannot take the distribution of
-variants in your running program into account. It is possible that the
-smaller variants make up less than 1% of all instances, in which case
-the overhead is negligible and the boxing is counter-productive. Always
-measure the change this lint suggests.
-
-For types that implement `Copy`, the suggestion to `Box` a variant's
-data would require removing the trait impl. The types can of course
-still be `Clone`, but that is worse ergonomically. Depending on the
-use case it may be possible to store the large data in an auxiliary
-structure (e.g. Arena or ECS).
-
-The lint will ignore the impact of generic types to the type layout by
-assuming every type parameter is zero-sized. Depending on your use case,
-this may lead to a false positive.
-
-### Example
-```
-enum Test {
-    A(i32),
-    B([i32; 8000]),
-}
-```
-
-Use instead:
-```
-// Possibly better
-enum Test2 {
-    A(i32),
-    B(Box<[i32; 8000]>),
-}
-```
\ No newline at end of file