You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This came up on the #scripting discord chat, but for many structs it should be possible to remove the requirement for #[repr(C)]. Since we're generating the struct definitions at runtime - at least, certainly for Lua - we can just have a struct that lets you specify offsets like so:
Then the backend can use this to generate a C-compatible struct definition on the fly, reordering fields and generating explicit padding bytes where necessary. This allows Rust to reorder fields and do whatever else but without sacrificing the ability to access those fields in the scripting layer.
This also allows us to support tuples and external types. For tuples, we can do something like so:
Then for external structs we can do something like so:
pubstructMyStruct{puba:Foo,pubb:Bar,}// ... in another crate ...structMyWrapper(MyStruct);implGetFieldsforMyWrapper{constFIELDS:FieldsDef<'static> = FieldsDef::Named(&[("a",offset_of!(MyStruct, 0.a)),("b",offset_of!(MyStruct, 0.b)),]);}
I've used an associated const in this, but it's worth noting that you could also support structs with runtime-defined layouts if you made it a fn. The only example I can think of is wasmtime's VMCtx, which isn't something that you'd be likely to pass to a script, but it's worth thinking about.
This could be very simply wrapped in a derive macro - if Rust supported macro_rules macros as annotations it'd even be simple enough to be implement using that.
The text was updated successfully, but these errors were encountered:
This came up on the #scripting discord chat, but for many structs it should be possible to remove the requirement for
#[repr(C)]
. Since we're generating the struct definitions at runtime - at least, certainly for Lua - we can just have a struct that lets you specify offsets like so:Then the backend can use this to generate a C-compatible struct definition on the fly, reordering fields and generating explicit padding bytes where necessary. This allows Rust to reorder fields and do whatever else but without sacrificing the ability to access those fields in the scripting layer.
This also allows us to support tuples and external types. For tuples, we can do something like so:
Then for external structs we can do something like so:
I've used an associated const in this, but it's worth noting that you could also support structs with runtime-defined layouts if you made it a
fn
. The only example I can think of is wasmtime's VMCtx, which isn't something that you'd be likely to pass to a script, but it's worth thinking about.This could be very simply wrapped in a
derive
macro - if Rust supportedmacro_rules
macros as annotations it'd even be simple enough to be implement using that.The text was updated successfully, but these errors were encountered: