Stream: git-wasmtime

Topic: wasmtime / PR #15048 Support `repr(C, _)` enums in `for_e...

view this post on Zulip Wasmtime GitHub notifications bot (Oct 28 2026 at 18:27):

fitzgen requested cfallin for a review on PR #15048.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 28 2026 at 18:27):

fitzgen removed the review request for wasmtime-compiler-reviewers from PR #15048.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 28 2026 at 18:27):

fitzgen requested wasmtime-core-reviewers for a review on PR #15048.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 28 2026 at 18:27):

fitzgen requested wasmtime-compiler-reviewers for a review on PR #15048.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 28 2026 at 18:27):

fitzgen opened PR #15048 from fitzgen:enums-in-for-each-vm-type-macro to bytecodealliance:main:

Needed for upcoming work to transfer borrows to their owner inline in adapters, rather than calling out to the host.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 28 2026 at 20:44):

github-actions[bot] added the label wasmtime:api on PR #15048.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 29 2026 at 14:28):

alexcrichton commented on PR #15048:

Personally I'll admit I basically have no idea any more what's going on in these macros, they're far beyond what I can keep in my head. Otherwise though can you detail a bit more about how the enum bits are integrated? For example how do alias regions work out? While structs can have a separate region-per-field with the nature of aliasing enums and being union-like I'd naively expect such aliasing to be much trickier with a perhaps temporary fallback of "one region per enum", but even then I'm not sure how struct-in-enum would interact since regions could then start overlapping.

Otherwise I'll also note that I've been historically surprised by the layout of #[repr(C)] enums in Rust. Layouts of them are surprisingly subtle and I've gotten it wrong in the C API when trying to mirror the Rust structures into C headers before. I don't understand enum layout enough really to know what went wrong, nor do I understand the macros enough to know if it would match up to rustc's layout, but I mostly wanted to point out that platforms are really weird in the full breadth of things and enums that works on one platform may not always work the same on others.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 29 2026 at 16:25):

fitzgen commented on PR #15048:

I don't know about any weird platform gotchas -- you would know about those better than me. FWIW, the macro-generated layout tests are passing everywhere we run them in CI. We could always manually define a struct { tag, union } to avoid supporting enums in this macro, but my understanding is that this is actually identical to what repr(C) on an enum does (correct me if I'm wrong!).

Right now it is generating a separate region per variant field, which is valid for the use cases I currently have that never change enum variants while Wasm code has access to the enum, but I think you are right that doing so could cause problems down the line. So conservatively using one region per enum (or one for the tag and one for the data) at least for now seems like a good idea.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 29 2026 at 16:58):

alexcrichton commented on PR #15048:

Reading over the Rust RFC for this I think I remember my historical confusion in the C API. Specifically #[repr(u8)] and #[repr(C, u8)] have entirely different layouts and I was historically not expecting that.

Re-reading that RFC I think it might be good to require #[repr(C, uNN)] here instead of just #[repr(C)] to explicitly say how big the tag is as opposed to using whatever the platform default is as that's pretty nebulous. Alternatively #[repr(uN)] could be used for the slight space savings if any of the enums being added actually benefit from it.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 29 2026 at 17:04):

fitzgen commented on PR #15048:

Re-reading that RFC I think it might be good to require #[repr(C, uNN)] here instead of just #[repr(C)] to explicitly say how big the tag is as opposed to using whatever the platform default is as that's pretty nebulous. Alternatively #[repr(uN)] could be used for the slight space savings if any of the enums being added actually benefit from it.

Yep, we do force repr(C, uNN) with an explicit uNN, instead of allowing plain repr(C): https://github.com/bytecodealliance/wasmtime/pull/15048/changes#diff-c2419e7dda6ababddf61ec427594de45d7710ed2e501264d8fd754635daaa7a8R1047

view this post on Zulip Wasmtime GitHub notifications bot (Oct 29 2026 at 17:17):

:thumbs_up: alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 29 2026 at 17:20):

fitzgen updated PR #15048.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 29 2026 at 17:20):

fitzgen has enabled auto merge for PR #15048.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 29 2026 at 17:29):

fitzgen added PR #15048 Support repr(C, _) enums in for_each_vm_type! to the merge queue

view this post on Zulip Wasmtime GitHub notifications bot (Oct 29 2026 at 22:11):

:check: fitzgen merged PR #15048.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 29 2026 at 22:11):

fitzgen removed PR #15048 Support repr(C, _) enums in for_each_vm_type! from the merge queue

Last updated: Oct 31 2026 at 23:03 UTC