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

rustc_target: factor out common fields of non-Single Variants. #59519

Merged
merged 1 commit into from
Mar 31, 2019

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Mar 29, 2019

@tmandry and I were discussing ways to generalize the current variants/discriminant layout to allow more fields in the "enum" (or another multi-variant types, such as potentially generator state, in the future), shared by all variants, than just the tag/niche discriminant.

This refactor should make it easier to extend multi-variant layouts, as nothing is duplicating anymore between "tagged enums" and "niche-filling enums".

r? @oli-obk

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 29, 2019
Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

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

r=me with tag access deduplicated

@@ -1586,8 +1596,11 @@ fn prepare_enum_metadata(
let layout = cx.layout_of(enum_type);

match (&layout.abi, &layout.variants) {
(&layout::Abi::Scalar(_), &layout::Variants::Tagged {ref tag, .. }) =>
return FinalMetadata(discriminant_type_metadata(tag.value)),
(&layout::Abi::Scalar(_), &layout::Variants::Multiple {
Copy link
Contributor

Choose a reason for hiding this comment

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

I've seen this code twice now (extracting the discr field if disc_kind is Tag. Pull it out into a method returning Option?

Copy link
Member Author

Choose a reason for hiding this comment

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

I disagree, these are orthogonal. I didn't want to rewrite too much code, but arguably everything should match on Variants and then match on DiscriminantKind inside the Multiple case.

That way, code common to both niches and tags can be reused. Adding a .tag() method runs counter to that.

Copy link
Contributor

Choose a reason for hiding this comment

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

I get that, but the three cases that I saw here all are very "tagged" special and can't share code with the niche part. Or do you see any additional refactorings that can be done here in the future?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah this is the special case for C-like enums. Either way, I don't see a point in catering to this pattern, but I'll leave comments regarding the possibility of refactoring on the other 2 cases.

discr_kind: layout::DiscriminantKind::Niche { .. },
..
} => None,
layout::Variants::Multiple {
Copy link
Contributor

Choose a reason for hiding this comment

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

thrice

Copy link
Member Author

Choose a reason for hiding this comment

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

This is in if use_enum_fallback(cx) and will eventually be removed when we stop supporting LLVM versions that predate the addition of variant debuginfo.

record(adt_kind.into(), adt_packed, match layout.variants {
Variants::Tagged { ref tag, .. } => Some(tag.value.size(self)),
record(adt_kind.into(), adt_packed, match discr_kind {
DiscriminantKind::Tag => Some(discr.value.size(self)),
Copy link
Contributor

Choose a reason for hiding this comment

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

first occurrence here

Copy link
Member Author

Choose a reason for hiding this comment

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

This whole thing needs to be rewritten to pretty-print layouts losslessly (or we can just use {:#?}, heh).

@oli-obk
Copy link
Contributor

oli-obk commented Mar 31, 2019

@bors r+

@bors
Copy link
Contributor

bors commented Mar 31, 2019

📌 Commit 5b7f4e9 has been approved by oli-obk

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 31, 2019
Centril added a commit to Centril/rust that referenced this pull request Mar 31, 2019
…li-obk

rustc_target: factor out common fields of non-Single Variants.

@tmandry and I were discussing ways to generalize the current variants/discriminant layout to allow more fields in the "`enum`" (or another multi-variant types, such as potentially generator state, in the future), shared by all variants, than just the tag/niche discriminant.

This refactor should make it easier to extend multi-variant layouts, as nothing is duplicating anymore between "tagged enums" and "niche-filling enums".

r? @oli-obk
bors added a commit that referenced this pull request Mar 31, 2019
Rollup of 7 pull requests

Successful merges:

 - #58805 (Lint for redundant imports)
 - #59506 (Use platform dependent mcount function)
 - #59519 (rustc_target: factor out common fields of non-Single Variants.)
 - #59580 (Allow closure to unsafe fn coercion)
 - #59581 (Stabilize refcell_replace_swap feature)
 - #59583 (match match match match match)
 - #59587 (Remove #[doc(hidden)] from Error::type_id)

Failed merges:

r? @ghost
@bors bors merged commit 5b7f4e9 into rust-lang:master Mar 31, 2019
@bors
Copy link
Contributor

bors commented Mar 31, 2019

⌛ Testing commit 5b7f4e9 with merge 4fac5c9...

@eddyb eddyb deleted the layout-variants-refactor branch March 31, 2019 20:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants