Test system for the Widl compiler

[Zebediah Figura]

On 6/15/22 13:52, Bernhard Kölbl wrote:
> 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.

Sure, but you can test that the same way. Just use the symbol somehow 
and check that it compiles. Am I missing something?