Lints to identify enums where variants have wildly different sizes #10362
Labels
A-lint
Area: Lints (warnings about flaws in source code) such as unused_mut.
Comments
|
Another challenge: size information isn't really available until trans. So this'll have to be a kind of guesstimate. But that's probably ok. |
|
Similar to, but not the same as #6600 |
|
We could possibly have a post-trans lint phase. |
Merged
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Mar 10, 2023
…=llogiq Add `missing_assert_message` lint Fixes rust-lang/rust-clippy#6207. changelog: new lint: [`missing_assert_message`]: A new lint for checking assertions that doesn't have a custom panic message. [rust-lang#10362](rust-lang/rust-clippy#10362) <!-- changelog_checked --> r? `@llogiq`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Because an enum takes the size of its largest member, it is very easy to have enums whose size grows surprisingly large if you are not careful.
ast::Expr, for example, is currently 120 bytes in our compiler. It'd be helpful to have a lint that checks the size of the smallest and largest variant in an enum and reports if the difference is "too" big. What "too big" means I don't know -- perhaps if one is 2x the other?One issue is what to do about generic enums. We could (for now) just assume that generics have a certain size, or else wait and report lint warnings on individual instantiations -- but this seems like a warning that should be associated with the def'n of the structure.
The text was updated successfully, but these errors were encountered: