Test system for the Widl compiler

[Bernhard Kölbl]

Am Mi., 15. Juni 2022 um 20:40 Uhr schrieb Zebediah Figura
<zfigura at 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.