GNOME Bugzilla – Bug 656931
Element types of lists broken
Last modified: 2015-02-07 16:59:53 UTC
Compilation of WebKit is broken with recent revisions of gobject-introspection due to this appearing in WebKit-3.0.gir (note the nested <type>s inside <return-value>): <method name="get_mimetypes" c:identifier="webkit_web_plugin_get_mimetypes" version="1.3.8" introspectable="0"> <doc xml:whitespace="preserve">Returns all the #WebKitWebPluginMIMEType that @plugin is handling at the moment.</doc> <return-value transfer-ownership="none"> <doc xml:whitespace="preserve">a #GSList of #WebKitWebPluginMIMEType</doc> <type name="GLib.SList" c:type="GSList*"> <type name="GLib.SList" c:type="GSList*"/> </type> </return-value> </method> 'git bisect' points at <http://git.gnome.org/browse/gobject-introspection/commit/?id=81abc2eb63317003a11d1484e84698a37e8ec035> as the culprit: commit 81abc2eb63317003a11d1484e84698a37e8ec035 Author: Johan Dahlin <johan@gnome.org> Date: Sat Aug 13 14:36:53 2011 -0300 Try harder to preserve c:type When we replace a type using annotation we should keep the ctype of the original type. And indeed, if you look at the diff, then the following stands out: <return-value transfer-ownership="container"> <doc xml:whitespace="preserve">list of strings</doc> <type name="GLib.List" c:type="GList*"> - <type name="utf8"/> + <type name="utf8" c:type="GList*"/> </type> </return-value> That seems incorrect. In the WebKit case, the return value type seems to only have a "c:type", not a "name", and this change then overwrites the "c:type".
How does it actually break? I also wonder what the expected c:ctype is for nested <type>s. My gut feeling is to remove them as it was before and make the documentation generator a bit smarter about types, especially nested ones.
(In reply to comment #1) > How does it actually break? ERROR:girepository/girnode.c:1381:_g_ir_node_build_typelib: assertion failed: (node != NULL) /bin/bash: line 1: 21277 Aborted /opt/gnomes/gnome/bin/g-ir-compiler --includedir ./Source/WebKit/gtk --includedir . WebKit-3.0.gir -o WebKit-3.0.typelib Here's the backtrace:
+ Trace 228154
Frame 5 has node = NULL. Frame 6 has node = {type = G_IR_NODE_TYPE, name = 0x0, module = 0x807dc28, offset = 201856, attributes = 0x9748388} Frame 7 has node = {type = G_IR_NODE_TYPE, name = 0x0, module = 0x807dc28, offset = 201796, attributes = 0x9748350} Frame 8 has node = {type = G_IR_NODE_FUNCTION, name = 0x97493a0 "get_mimetypes", module = 0x807dc28, offset = 201552, attributes = 0x97482e0} function = {node = {type = G_IR_NODE_FUNCTION, name = 0x97493a0 "get_mimetypes", module = 0x807dc28, offset = 201552, attributes = 0x97482e0}, deprecated = 0, is_varargs = 0, is_method = 1, is_setter = 0, is_getter = 0, is_constructor = 0, wraps_vfunc = 0, throws = 0, symbol = 0x9749430 "webkit_web_plugin_get_mimetypes", result = 0x9749458, parameters = 0x0} function->result = {node = {type = G_IR_NODE_PARAM, name = 0x0, module = 0x807dc28, offset = 201796, attributes = 0x9748318}, in = 0, out = 0, caller_allocates = 0, optional = 0, retval = 1, allow_none = 0, skip = 0, transfer = 0, shallow_transfer = 0, scope = GI_SCOPE_TYPE_INVALID, closure = 0 '\000', destroy = 0 '\000', type = 0x9749510} function->result->type = {node = {type = G_IR_NODE_TYPE, name = 0x0, module = 0x807dc28, offset = 201796, attributes = 0x9748350}, is_pointer = 1, is_basic = 0, is_array = 0, is_glist = 0, is_gslist = 1, is_ghashtable = 0, is_interface = 0, is_error = 0, tag = 18, unparsed = 0x9749380 "GLib.SList", zero_terminated = 0, has_length = 0, length = 0, has_size = 0, size = 0, array_type = 0, parameter_type1 = 0x97495a0, parameter_type2 = 0x0, interface = 0x0, errors = 0x0} > I also wonder what the expected c:ctype is for nested <type>s. > My gut feeling is to remove them as it was before and make the documentation > generator a bit smarter about types, especially nested ones. Why should nested <type>s be treated specially? Shouldn't their "c:type" simply correspond to their "type"?
You can revert the change if you want, I have no time to update/fix it at the moment.
*** Bug 657267 has been marked as a duplicate of this bug. ***
I'm a bit confused by this one; Johan's change doesn't seem like it should cause this effect. Torsten - while you're right that that the diff is suboptimal, what's actually making g-ir-compiler crash is that the inner <type name="GLib.SList"> has no element type. I'm going to see what GIR the scanner produced before the change.
So clearly before we get: <type name="GLib.SList" c:type="GSList*"> <type c:type="WebKitWebPluginMIMEType"/> </type> Which is what's desired.
commit cef390f65ffe9e51b103fcb29ee177882f762a0e Author: Colin Walters <walters@verbum.org> Date: Mon Aug 29 22:17:02 2011 -0400 scanner: Don't try to copy c:type if we're parsing (element-type) Commit 81abc2eb63317003a11d1484e84698a37e8ec035 tries harder to keep the c:type if it was overriden by a (type) annotation. However, the _resolve() function was also called for (element-type), which had undesirable effects - we'd copy the container c:type to the element type. Fix this by splitting out the c:type preservation to only happen when processing toplevel types. https://bugzilla.gnome.org/show_bug.cgi?id=656931
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]