-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Conversation
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thrice
There was a problem hiding this comment.
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)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
first occurrence here
There was a problem hiding this comment.
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).
@bors r+ |
📌 Commit 5b7f4e9 has been approved by |
…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
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
@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