Ryan Hunt
Ryan Hunt
Hmm, so I think we can generate the following to handle this: ```c++ #ifndef _MSC_VER // might need some fudging depending on where the attribute needs to go in the...
@Michael-F-Bryan Yes, that sounds reasonable to me. You'll need to have a pass to detect what macros should be declared at the top, and it'd be best if this worked...
My comments earlier were wrong. `cbindgen` used to refuse to parse paths that had multiple segments. This wasn't great so I fixed it in 015572877a9eec5b538c71ff73ddedae40e6210c.
Unfortunately, I'm not sure there is a workaround yet besides renaming the types. My first thought would have been to use the structs behind type aliases with different names, but...
Yeah that totally makes sense. I'll delay this for a couple weeks.
Yeah that should be do-able. I'll try and prototype something sometime.
That proposal seems reasonable from a `cbindgen` perspective, If we're attempting to provide fields equivalent to repr(rust) we'll need to parse $type_name with syn. But that shouldn't be a problem.
My understanding is that this isn't feasible because of ABI function calling rules. Specifically, matching the alignment and size of two structs is not sufficient to have them be passed...
To add to this discussion (very late), I agree that a warning/error would be good here. Leaning towards an error.
Okay, had some time to read and think through this a bit. The current proposal for wasm compile-time imports only touches the Wasm JS-API and avoids touching the core wasm...