https://bugs.winehq.org/show_bug.cgi?id=54226
--- Comment #2 from Alvin Wong alvin@alvinhc.com --- (In reply to Zeb Figura from comment #1)
(In reply to Alvin Wong from comment #0)
(I have not checked what `/cstruct_out` on MIDL actually does to the C bindings.)
This, basically:
[snip]
Thanks for checking.
But we already emit the C type definition (the first hunk) with ABI compatibility in all cases.
Ah yes, so this part is fine.
For the macro we currently have e.g.
#define ID2D1Bitmap_a(This) (This)->lpVtbl->a(This) #define ID2D1Bitmap_b(This) ID2D1Bitmap_b_define_WIDL_C_INLINE_WRAPPERS_for_aggregate_return_support
but is there really any point to doing this? Do we care about API compatibility if the API is just broken? Should we just implement the ABI-compatible behaviour for the macros and not bother checking cstruct_out?
That's true, a broken API is useless anyway. I don't mind for widl to just generate the same form as `midl /cstruct_out`, so it would become
#define ID2D1Bitmap_b(This,__ret) (This)->lpVtbl->b(This,__ret)
and if we only consider this then we perhaps don't need a --cstruct_out option. The existing "%s_%s_define_WIDL_C_INLINE_WRAPPERS_for_aggregate_return_support" obviously doesn't work.
But what about the inline functions defined when `WIDL_C_INLINE_WRAPPERS` is defined? Changing this bit may actually break existing code: https://github.com/mingw-w64/mingw-w64/blob/a57cacad31f5766d45959b6c0f9b1229...
---
I _think_ the intention of the new flag in the case of MSVC would be to maintain backward compatibility for when someone has implemented their own COM objects with the vtable in C and only use them from C, in which case the "broken" behaviour works fine and the new "correct" behaviour would actually break things. This does not apply to widl and mingw-w64 because widl has already been emitting the "correct" C vtable.