Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

large_enum_variants lint suggests to box variants above a configurable limit #1492

Merged
merged 4 commits into from
Jan 31, 2017

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Jan 30, 2017

fixes #1127
obsoletes #1187

//! lint when there are large variants on an enum

use rustc::lint::*;
use rustc::hir::*;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, fortunately you did not promise 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in my defense, I only rebased this code ;)

Copy link
Member

@mcarton mcarton Jan 31, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my defense, this does not appear in either the commit info (“@foo committed with @bar”), the first commit message, the blame info (you don't seem to have used git rebase?), or the PR's comment (“obsoletes #xyz” implies this is more than just a rebase).

use rustc::ty::TypeFoldable;
use rustc::traits::Reveal;

/// **What it does:** Checks for large variants on enums.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer “enumeration” or “enums”.

LARGE_ENUM_VARIANT,
def.variants[i].span,
&format!("large enum variant found on variant `{}`", variant.name),
"consider boxing the large branches to reduce the total size of the enum");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Make a suggestion if there is only one field?
  • s/branch/field

}

enum LargeEnumGeneric<A: SomeTrait> {
Var(A::Item), // regression test, this used to ICE
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You add regression tests even before the PR is merged? 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got tired of fixing multiple commits during rebasing and simply merged them into one

@mcarton mcarton merged commit b1be0d6 into master Jan 31, 2017
@mcarton mcarton deleted the largeEnumVariant branch January 31, 2017 18:12
@Arnavion
Copy link
Contributor

Arnavion commented Feb 4, 2017

@Arnavion
Copy link
Contributor

Arnavion commented Feb 4, 2017

Also, this lint warns on all variants that exceed 200 bytes in size, as opposed to if the difference between the smallest and largest variant exceeds 200 bytes. Is that intentional? The latter seems to make more sense to me.

Edit: From #rust:

<Arnavion> So, clippy add the (as yet undocumented) lint recently that warns if an enum variant is more than 200 bytes and suggests boxing the fields of the variant. The justification is "Enum size is bounded by the largest variant. Having a large variant can penalize the memory layout of that enum."
<Arnavion> Is that really a valid reason? Or should the lint be warning if the *difference* between the smallest and largest fields is more than 200 bytes?
<rkruppe-phone> Arnavion: yeah relative sizes between variants sounds more correct (I wouldn't use 200 bytes as cut off though)

Edit: This was fixed in https://github.com/Manishearth/rust-clippy/pull/1512

@Manishearth
Copy link
Member

Updated the wiki.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Suggest to store large enum variants as Box
4 participants