GNOME Bugzilla – Bug 634034
Vala 0.11.x generates bindings that are missing function parameters
Last modified: 2010-11-08 18:32:36 UTC
Vala 0.11.x generates some bindings for telepathy-glib that are missing parameters for functions (which were correct in 0.10.x). We've had trouble with the way g-i and Vala handled the fact that TpHandle is a guint before, though those seem to be correct in both cases here. I wonder, since that's the type of parameter that's missing from this function. ======================================================================= GIR segments ======================================================================= <alias name="Handle" c:type="TpHandle"> <doc xml:whitespace="preserve">Type representing Telepathy handles within telepathy-glib. This is guint despite the wire protocol having 32-bit integers, because dbus-glib expects GArrays of guint and so on. If the dbus-glib ABI changes in future, telepathy-glib is likely to have a matching ABI change.</doc> <type name="guint" c:type="guint"/> </alias> ... <method name="group_get_handle_owner" c:identifier="tp_channel_group_get_handle_owner"> <return-value transfer-ownership="none"> <type name="Handle" c:type="TpHandle"/> </return-value> <parameters> <parameter name="handle" transfer-ownership="none"> <type name="Handle" c:type="TpHandle"/> </parameter> </parameters> </method> ======================================================================= VAPI segments (note the missing parameter for group_get_handle_owner()) ======================================================================= [CCode (cheader_filename = "telepathy-glib/telepathy-glib.h")] [SimpleType] [IntegerType (rank = 0)] public struct Handle : uint { } public class Channel : TelepathyGLib.Proxy { ... public TelepathyGLib.Handle group_get_handle_owner (); }
Created attachment 173856 [details] The GIR file
Created attachment 173857 [details] the VAPI file
Created attachment 173864 [details] VAPI generated with switch-to-gir branch This seems to be fixed in the switch-to-gir branch. Here is a VAPI generated from attachment #173856 [details] using the switch-to-gir branch.
The latest status: The switch-to-gir branch fixes most of the problems. However, a few existing fixes need to be applied: * GLib.ContentType's gir_namespace and gir_version need to be stripped. * telepathy-glib needs TelepathyGLib-0.12.metadata added to telepathy-glib/telepathy/glib. This works around the fact that the switch-to-gir branch doesn't pick up on the namespace from the GIR file (which may or may not be fixed when this branch is merged). The metadata file's contents are: * TelepathyGLib name="TelepathyGLib" Unfixed issues: * In Folks, a lot of our lambda functions have a parameter named "_error_" but refer to it in the function body as "error". This is obviously not related to the switch to GIR files, but is nonetheless part of the switch-to-gir branch which needs to be fixed.
Just merged switch-to-gir. According to Jürg (on IRC), the _error_ issue should be fixed. The gir_* CCode attributes are stripped from nested namespaces. The remaining issue is the metadata file for changing the namespace. Currently, the generated namespaces are based on the namespace c:identifier-prefixes attribute, not the namespace name attribute. I'm honestly not sure which way makes more sense. I'm going to close this bug, but feel free to open another one for that issue, or bring it up on #vala and we can try to decide whether it is a bug or not.
(In reply to comment #5) > Just merged switch-to-gir. According to Jürg (on IRC), the _error_ issue should > be fixed. The gir_* CCode attributes are stripped from nested namespaces. Yup, this seems fixed. > The remaining issue is the metadata file for changing the namespace. Currently, > the generated namespaces are based on the namespace c:identifier-prefixes > attribute, not the namespace name attribute. I'm honestly not sure which way > makes more sense. I'm going to close this bug, but feel free to open another > one for that issue, or bring it up on #vala and we can try to decide whether it > is a bug or not. We decided this is basically an anti-bug -- it was wrong, but the new way is correct. We've adjusted for this in telepathy-glib to keep a consistent namespace.