Well we're also missing, that Widl provides valid C++ headers and that'd have to introduce C++ into Wine.
Am Mi., 15. Juni 2022 um 21:08 Uhr schrieb Zebediah Figura zfigura@codeweavers.com:
On 6/15/22 13:52, Bernhard Kölbl wrote:
Am Mi., 15. Juni 2022 um 20:40 Uhr schrieb Zebediah Figura zfigura@codeweavers.com:
On 6/15/22 13:24, Bernhard Kölbl wrote:
We already have tests for typelibs and marshalling, in oleaut32:typelib and oleaut32:tmarshal respectively. I see no reason that's not sufficient already.
As far as headers are concerned, we could probably take a similar approach in some ways. I don't know what exactly needs testing, but we could do things like
ok(offsetof(mystruct.field) == 16, "wrong offset %u\n", offsetof(mystruct.field));
or (for a compile-time assertion)
extern void test(ITestInterface *obj) { HRESULT (*myfunc)(type1 arg1, type2 *arg2, ...);
myfunc = obj->lpVtbl->myfunc;
}
This won't work for some WinRT features like namespaces and some attributes.
What needs testing there? Is there anything to do aside from validating that a given IDL compiles? That too doesn't seem like it'd require any extra test infrastructure.
For example we want to check if Widl compiles interface Windows.Foundation.TypedEventHandler<Windows.ApplicationModel.PackageCatalog*, Windows.ApplicationModel.PackageContentGroupStagingEventArgs*>; to __FITypedEventHandler_2_Windows__CApplicationModel__CPackageCatalog_Windows__CApplicationModel__CPackageContentGroupStagingEventArgs istead of sth like __FITypedEventHandler_1_Windows__CApplicationModel__CPackageCatalog_Windows__CApplicationModel__CPackageContentGroupStagingEventArgs
Sure, it would compile, but we'd lose output matching to Midl on our end.
Sure, but you can test that the same way. Just use the symbol somehow and check that it compiles. Am I missing something?