Re: [2/2] widl: Fix generation of a typelib for winhttp.
On 2 Oct 2015, at 03:25, Dmitry Timoshkov wrote:
diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c index 26600e4..7973113 100644 --- a/tools/widl/write_msft.c +++ b/tools/widl/write_msft.c @@ -974,8 +974,7 @@ static int encode_type( { int typeinfo_offset;
- /* typedef'd types without public attribute aren't included in the typelib */ - while (type->typelib_idx < 0 && type_is_alias(type) && !is_attr(type->attrs, ATTR_PUBLIC)) + while (type->typelib_idx < 0 && type_is_alias(type)) type = type_alias_get_aliasee(type);
chat("encode_type: VT_USERDEFINED - type %p name = %s real type %d idx %d\n", type, @@ -1836,7 +1835,7 @@ static msft_typeinfo_t *create_msft_typeinfo(msft_typelib_t *typelib, enum type_ MSFT_TypeInfoBase *typeinfo; MSFT_GuidEntry guidentry;
- chat("create_msft_typeinfo: name %s kind %d\n", name, kind); + chat("create_msft_typeinfo: name %s kind %d, index %d\n", name, kind, typelib->typelib_header.nrtypeinfos);
msft_typeinfo = xmalloc(sizeof(*msft_typeinfo)); memset( msft_typeinfo, 0, sizeof(*msft_typeinfo) ); @@ -2307,9 +2306,7 @@ static void add_entry(msft_typelib_t *typelib, const statement_t *stmt) { const type_list_t *type_entry = stmt->u.type_list; for (; type_entry; type_entry = type_entry->next) { - /* if the type is public then add the typedef, otherwise attempt - * to add the aliased type */ - if (is_attr(type_entry->type->attrs, ATTR_PUBLIC)) + if (type_get_type(type_entry->type) == TYPE_BASIC) add_typedef_typeinfo(typelib, type_entry->type); else add_type_typeinfo(typelib, type_alias_get_aliasee(type_entry->type));
Doesn't this essentially make [public] a nop? That seems wrong. The WinHttpRequestOption enum has a [uuid] attribute, so that probably has something to do with it. Huw.
Huw Davies <Huw.Davies(a)physics.ox.ac.uk> wrote:
@@ -2307,9 +2306,7 @@ static void add_entry(msft_typelib_t *typelib, const statement_t *stmt) { const type_list_t *type_entry = stmt->u.type_list; for (; type_entry; type_entry = type_entry->next) { - /* if the type is public then add the typedef, otherwise attempt - * to add the aliased type */ - if (is_attr(type_entry->type->attrs, ATTR_PUBLIC)) + if (type_get_type(type_entry->type) == TYPE_BASIC) add_typedef_typeinfo(typelib, type_entry->type); else add_type_typeinfo(typelib, type_alias_get_aliasee(type_entry->type));
Doesn't this essentially make [public] a nop? That seems wrong.
The WinHttpRequestOption enum has a [uuid] attribute, so that probably has something to do with it.
I have tested typedefs with various types and was also wondering about [public] attribute: regardless of its existence midl generates identical typelibs. -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Huw Davies <Huw.Davies(a)physics.ox.ac.uk> wrote:
@@ -2307,9 +2306,7 @@ static void add_entry(msft_typelib_t *typelib, const statement_t *stmt) { const type_list_t *type_entry = stmt->u.type_list; for (; type_entry; type_entry = type_entry->next) { - /* if the type is public then add the typedef, otherwise attempt - * to add the aliased type */ - if (is_attr(type_entry->type->attrs, ATTR_PUBLIC)) + if (type_get_type(type_entry->type) == TYPE_BASIC) add_typedef_typeinfo(typelib, type_entry->type); else add_type_typeinfo(typelib, type_alias_get_aliasee(type_entry->type));
Doesn't this essentially make [public] a nop? That seems wrong.
The WinHttpRequestOption enum has a [uuid] attribute, so that probably has something to do with it.
I have tested typedefs with various types and was also wondering about [public] attribute: regardless of its existence midl generates identical typelibs.
Forgot to mention that [uuid] attribute also changes nothing for the enum type generation. -- Dmitry.
On Fri, Oct 02, 2015 at 05:04:55PM +0800, Dmitry Timoshkov wrote:
Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
I have tested typedefs with various types and was also wondering about [public] attribute: regardless of its existence midl generates identical typelibs.
Forgot to mention that [uuid] attribute also changes nothing for the enum type generation.
Sure it does. Try this: [ uuid(12345678-0000-0000-0000-000000000000), ] library foo { typedef [public] int x; typedef int y; typedef [uuid(12345678-9000-0000-0000-000000000000)] int z; } x and z are included, yet y isn't. Huw.
Huw Davies <huw(a)codeweavers.com> wrote:
I have tested typedefs with various types and was also wondering about [public] attribute: regardless of its existence midl generates identical typelibs.
Forgot to mention that [uuid] attribute also changes nothing for the enum type generation.
Sure it does. Try this:
[ uuid(12345678-0000-0000-0000-000000000000), ] library foo { typedef [public] int x; typedef int y; typedef [uuid(12345678-9000-0000-0000-000000000000)] int z; }
This typelib definition doesn't seem to include an 'enum' type. -- Dmitry.
On 2 Oct 2015, at 11:41, Dmitry Timoshkov wrote:
Huw Davies <huw(a)codeweavers.com> wrote:
I have tested typedefs with various types and was also wondering about [public] attribute: regardless of its existence midl generates identical typelibs.
Forgot to mention that [uuid] attribute also changes nothing for the enum type generation.
Sure it does. Try this:
[ uuid(12345678-0000-0000-0000-000000000000), ] library foo { typedef [public] int x; typedef int y; typedef [uuid(12345678-9000-0000-0000-000000000000)] int z; }
This typelib definition doesn't seem to include an 'enum' type.
Right, but your patch breaks this case (it leads to y being included). That will affect stdole2.tlb, for example. I was trying to demonstrate the [public] shouldn't just be ignored. Huw.
Huw Davies <huw(a)codeweavers.com> wrote:
I have tested typedefs with various types and was also wondering about [public] attribute: regardless of its existence midl generates identical typelibs.
Forgot to mention that [uuid] attribute also changes nothing for the enum type generation.
Sure it does. Try this:
[ uuid(12345678-0000-0000-0000-000000000000), ] library foo { typedef [public] int x; typedef int y; typedef [uuid(12345678-9000-0000-0000-000000000000)] int z; }
This typelib definition doesn't seem to include an 'enum' type.
Right, but your patch breaks this case (it leads to y being included). That will affect stdole2.tlb, for example. I was trying to demonstrate the [public] shouldn't just be ignored.
I got the point about [public], thanks. Looks like I have to test this patch a little bit more. -- Dmitry.
On 2 Oct 2015, at 12:10, Dmitry Timoshkov wrote:
I got the point about [public], thanks. Looks like I have to test this patch a little bit more.
When you're testing, try setting the enum tag name and the typedef name to be same (as they are in httprequest.idl) and also the different names. It's also possible that using the typedef (in a method argument, for example) may result in different behaviour to just declaring it. Huw.
Huw Davies <huw(a)codeweavers.com> wrote:
When you're testing, try setting the enum tag name and the typedef name to be same (as they are in httprequest.idl) and also the different names.
That looks like a real source of the problem: if the tag and typedef names are the same then midl doesn't add a typedef'ed name information to typelib, when the names differ - then two typedef entries get creates: an alias for the typedef and real typedef for a tag. I have a patch that fixes this bug.
It's also possible that using the typedef (in a method argument, for example) may result in different behaviour to just declaring it.
Using the typedef in addition to just declaring it doesn't seem to cause a difference in the typelib generation. -- Dmitry.
participants (3)
-
Dmitry Timoshkov -
Huw Davies -
Huw Davies