[PATCH 04/13] oleaut32/tests: Cover GetVarDesc in test_dump_typelib.

[Puetz Kevin A]

> -----Original Message-----
> From: Marvin <testbot at winehq.org>
> Subject: Re: [PATCH 04/13] oleaut32/tests: Cover GetVarDesc in test_dump_typelib.
> 
> Hi,
> 
> While running your changed tests, I think I found new failures.
> Being a bot and all I'm not very good at pattern recognition, so I might be
> wrong, but could you please double-check?
> 
> Full results can be found at:
> https://testbot.winehq.org/JobDetails.pl?Key=76622
> 
> Your paranoid android.
> 
> === w1064v1809 (64 bit report) ===
> 
> oleaut32:
> typelib.c:5290: Interface test_struct
> typelib.c:5402: Variable hr
> typelib.c:5402: Variable b
> typelib.c:5402: Variable disp
> typelib.c:5402: Variable bstr
> typelib.c:5416: Test failed: desc->u.oInst expected 12 got 16

The failures in test_struct are because the field offsets really are different in a 64-bit typelib; the pointers for IDispatch *disp gets bigger, so BSTR bstr moved. I'm not sure how best to fix that; I could easily #ifdef the expected .oInst values, but then it will be a pain to regenerate the info[] stuff that's inlined into typelib.c. Function pointers normalize this checking the index (divided by offset/sizeof(void*) but that doesn't work for var since fields aren't all pointers, just (maybe) some of them. I suppose one could build test_tlb.tlb with --win32 (or --win64) so that it's a consistent set of input data, not architecture-dependent? Suggestions welcome if anyone has a good idea...

Or I could just skip verifying oInst; it's not really related to the custdata or FUNC_DISPATCH bug fixes that were the point of this series, it just wasn't covered before because the whole VARDESC was ignored before, so I tried to fill in some conformance-test coverage, not just narrowly check the fix. Which paid off because I found several more bugs in the FUNC_DISPATCH stuff than the one I started working on...

> typelib.c:5290: Interface _f
> typelib.c:5402: Variable f1
> typelib.c:5402: Variable f2
> typelib.c:5416: Test failed: desc->u.oInst expected 4 got 8
> typelib.c:5290: Interface ff
> typelib.c:5402: Variable ff1
> typelib.c:5402: Variable ff2
> typelib.c:5416: Test failed: desc->u.oInst expected 4 got 8

These look look like Marvin actually found a latent widl bug (on x86 too), that just happened to show up in the new coverage. _f and ff are unions, so the offsets should all be 0, but it apparently counted them like a struct. And since that's what the typelib actually says, windows oleaut32 agrees (on x86, where these info[] came from). So these would clear up (and not be architecture-dependent) if I can find the right spot in widl to fix oInst for unions - will check into it tomorrow.