1 files changed, 41 insertions, 0 deletions
diff --git a/src/tools/clippy/src/docs/large_enum_variant.txt b/src/tools/clippy/src/docs/large_enum_variant.txt
new file mode 100644
index 000000000..1f9543079
--- /dev/null
+++ b/src/tools/clippy/src/docs/large_enum_variant.txt
@@ -0,0 +1,41 @@
+### 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