Feasibility of supporting `#[repr(Rust)]` enums

[samscott89]

Update: as of #157 / #163 this is exclusively about #[repr(Rust)]

Previous description

Currently EnumDef requires an explicit primitive representation for enums to work, and this is enforced by the derive macro (or at least, will be with #139).

Supporting either #[repr(C)] or #[repr(Rust)] (the default representation) would require understanding the layout of the enum, which is non-trivial.

In the case of #[repr(C)], it might be feasible to do a similar trick with using the shadow struct for the enum variants, but also build a shadow struct for the tag, and use the two to compute the layout of the resultant struct as described here: https://doc.rust-lang.org/reference/type-layout.html#r-layout.repr.c.adt

For #[repr(Rust)] doing this layout matching seems entirely infeasible. There are the various "niche" optimizations for enums (nice post here), and there are no offset_of equivalents for enum variants that can get us this information.

I'm not sure if there are any tricks out there to make this work?

(Note: this is not something I'm personally blocked on, just noting it as a potential future issue).

Currently EnumDef requires an explicit primitive or c-style representation for enums to work, and this is enforced by the derive macro.

For #[repr(Rust)] doing this layout matching seems entirely infeasible. There are the various "niche" optimizations for enums (nice post here), and there are no offset_of equivalents for enum variants that can get us this information.

I'm not sure if there are any tricks out there to make this work?

(Note: this is not something I'm personally blocked on, just noting it as a potential future issue).

[samscott89]

I've made a little progess on supporting #[repr(C)].

The existing test case is actually a great one:

    #[repr(C)]
    #[allow(dead_code)]
    enum FooBar {
        Unit,
        Foo(u32),
        Bar(String),
        StructLike { a: u32, b: String },
    }

Because it has the following properties (at least, on macos, debug build):

• The discriminant is u32 (4 bytes). So confirms the existing heuristic doesn't work
• However, the StructLike variant is 40 with alignment of 8
• Which causes the overall enum to have alignment 8
• Which means that the "data" portion of the enum to have offset 8 (rather than the discriminant size).

I think the cleanest approach to make this work would be to create a completely different mechanism for deriving #[repr(C)] enums which makes shadow union types in order to compute the offsets correctly. I tried a few other lazier methods, but ultimately this seems like the best/only way.

Here's a POC of the manual implementation of this: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=c3f7fd661446a53572a202b0ef8b7847

As a bonus, it'd then be straightforward to support more esoteric reprs like #[repr(C, u8)] because all that changes is that the discriminant gets #[repr(u8)] instead.

I'm going to pause on this here though unless there's actually a reasonable desire for this as a feature.

[fasterthanlime]

I'm going to pause on this here though unless there's actually a reasonable desire for this as a feature.

I am definitely interested in that feature!

[samscott89]

Updated title + description to scope this to #[repr(Rust)]. Probably blocked on some combination of size_of for discriminators and offset_of for enum variants.

[A-Walrus]

Probably blocked on some combination of size_of for discriminators and offset_of for enum variants.

I'm not sure even those would be enough, wouldn't we need to be able to know what the discriminator for each variant is, if and where there is a niche, etc?

[samscott89]

Yeah, that sounds right to me.

[fee1-dead]

Landed upon this issue because I looked into ways to walk fields of a user ADT and was wondering whether facet would support that (cc #685). (I could also just use macro-rules-attribute instead, but this might be more fun)

It seems like the current design isn't well-equipped enough to support this, at least not without the offset_of_enum feature plus the Unsafe Set Enum Discriminants RFC.

I can also think of some workarounds, though. For example, when storing variant data there could be a function pointer called test for each variant that takes a reference to the type itself and returns whether the runtime value matches that variant.

Finding out about the offset of fields in the enum is harder without using offset_of_enum. A runtime function pointer to get reference to the field from a reference to the enum might still work, but that depends on whether this fits with the goals of the crate to justify the additional overhead of these generated code (OTOH, the derive wouldn't have supported repr(Rust) enums anyways..)