clippy::large_enum_variant should suggest Option<Box<T>> over Box<Option<T>>

[frxstrem]

Description

Consider this example:

struct LargeValue([u8; 201]);

enum Foo {
    Large(Option<LargeValue>),
    Small,
}

Running cargo clippy gives this warning:

warning: large size difference between variants
 --> src/lib.rs:3:1
  |
3 | / enum Foo {
4 | |     Large(Option<LargeValue>),
  | |     ------------------------- the largest variant contains at least 202 bytes
5 | |     Small,
  | |     ----- the second-largest variant carries no data at all
6 | | }
  | |_^ the entire enum is at least 202 bytes
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#large_enum_variant
  = note: `#[warn(clippy::large_enum_variant)]` on by default
help: consider boxing the large fields to reduce the total size of the enum
  |
4 |     Large(Box<Option<LargeValue>>),
  |           ~~~~~~~~~~~~~~~~~~~~~~~

Boxing an option is inefficient in the case of None, since it still needs to allocate the None on the heap and it can't take advantage of null pointer optimization. Instead, the lint should suggest Option<Box<LargeValue>> when the original field is Option<LargeValue>.

Version

rustc 1.67.0-nightly (a28f3c88e 2022-11-20)
binary: rustc
commit-hash: a28f3c88e50a77bc2a91889241248c4543854e61
commit-date: 2022-11-20
host: x86_64-apple-darwin
release: 1.67.0-nightly
LLVM version: 15.0.4

Additional Labels

No response

[mvolfik]

I don't have any insight into the internals of clippy, but I would guess that detecting cases like this would add unnecessary complexity. However, I just noticed some of my own code where I accidentally did Box<Option<T>>, and thought - why isn't there a lint that would catch that? (So that after the user applies the suggestion above, clippy raises another suggestion to further improve the code and invert it.) And while researching, I came across this issue.

So my question is - would it be worth creating a new lint for that? And can it be somehow generalized? Because I couldn't think of any other cases similar to Box<Option<T>> that could be "inverted"

[Centri3]

@rustbot claim

[Centri3]

Opened #10960, which while it doesn't cover changing the suggestion should work