diff options
Diffstat (limited to '')
-rw-r--r-- | src/tools/clippy/src/docs/large_enum_variant.txt | 41 |
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 |