GNOME Bugzilla – Bug 634588
Gio-2.0.gir 'take_error' parse error
Last modified: 2011-07-21 06:38:02 UTC
Compiling with vala trunk and trying to use gir support for Gio-2.0, I ran into the following parse error: Gio-2.0.gir:35338.9-35338.8: error: `SimpleAsyncResult' already contains a definition for `take_error' <parameters> Gio-2.0.gir:35064.9-35064.8: note: previous definition of `take_error' was here <parameters> Looking at the gir file, I see that the only two references to take_error are: Line 35059: <constructor name="new_take_error" c:identifier="g_simple_async_result_new_take_error"> Line 35333: <method name="take_error" c:identifier="g_simple_async_result_take_error"> They don't *look* like they should conflict.
Named constructors are in the same namespace as methods.
So is this a bug in vapigen or in the GIR for Gio? We are seeing this in 0.11.2 in Ubuntu.
It's not a bug neither in gir nor in gio. You want a Gio-2.0.metadata to skip it like: SimpleAsyncResult.new_take_error skip Or maybe you want to rename it with name="something_else". Closing as not a bug. Thanks for reporting..
I'm confused by the suggested fix. Why would gio upstream want to skip or rename that function? It's part of the API and is presumably useful. Both those functions are accessible in pygobject: >> from gi.repository import Gio >>> Gio.SimpleAsyncResult.new_take_error <bound method GObjectMeta.new_take_error of <class 'gi.repository.Gio.SimpleAsyncResult'>> >>> Gio.SimpleAsyncResult.take_error <unbound method SimpleAsyncResult.take_error> It sounds like this is a bug in vala that it can't handle this situation. Jürg said that "named constructors are in the same namespace as methods", so I assume the fix is to make that not true, right? Other well-meaning gir files will presumably hit this too.
No, I didn't say gio upstream has to skip or rename the function, it's in vala using a metadata format that is available to transform/fix the mapping between gir and vala. Why is it a bug in vala? Vala has a class scope and it's how it works. Not all things are bugs because it's the design of the language. Not all features of an external language can be mapped into another language and viceversa, you have to do some transformation. If the goal of Vala is to support this (Jurg will say), then it's a feature request, otherwise you have to adapt that function vala-side with a rename/skip using gir metadata.
Ah, OK. I was under the impression a .metadata file was something the upstream used while generating the gir. But all the metadata there is from source comments, isn't it. Metadata renaming is a fine suggestion then. Why was this closed as NOTABUG then? Seems like there's vala-side (bindings) work?
Because gio-2.0.vapi is not yet generated from gir in vala. Therefore if you're generating gio on your own, you decide how to generate the bindings and write your own Gio-2.0.metadata.
Oh, if the metadata file is only a vapi thing, then it's not very relevant for this bug. This bug is about using straight gir. From my perspective, the upstream gio gir file is great already. Python can use both functions fine and it seems spec-compliant to me. So the question is, how to fix valac to be able to correctly parse the existing gio gir file (and any other girs that happen to have 'new' functions with similar names to normal functions). That's why I think there is still a valac bug here. It seems like valac needs some tweaking to handle these (valid gir) cases.
Metadata is for gir for tweaking the generated vapi. Python and Vala are two different languages, so where python can win vala fails, and viceversa. In this case python has only one constructor while vala not. Plus you still don't map directly from gir to python, because there are "overrides" in python as well (http://git.gnome.org/browse/pygobject/tree/gio), again as I said because you can't always do a direct mapping from another language to another language without human interaction.
Forgot to say, metadata is needed as well for using gir without generating the vapi.
I guess I'm just looking for guidance as to what to do now. You say it's not a bug in vala. Is your recommendation that I should file a bug against upstream gio asking them to ship a metadata file that works around this for vala? Is the metadata file vala-specific or would it affect all gir consumers?
As I understand this, it's purely your experiment. Either tweak your bindings with metadata, or use bindings distributed with valac, or (if you are bad-ass enough) get upstream gio to modify their gir to take Vala into account, or (if you are even more bad-ass) get Vala devs to auto-mangle conflicting names.
Metadata is vala-specific. Gir can't be fixed upstream unless they want to change the name of the method, therefore impossible. You either want: 1) That vala smartly changes the name of the constructor, but most of the time it's not going to be what people doing bindings want, and this requires a smart patch 2) Use a Gio-2.0.metadata file tweaking the gir usage in vala, fast and painless way 3) Request vala to have a separate scope for constructors, that won't be anytime soon My Gio-2.0.metadata follows (incomplete and works with switch-to-gir branch): Gio name="GLib" content_type_* parent="GLib.ContentType" name="content_type_(.*)" *.cancellable nullable default=null *.*.cancellable nullable default=null BufferedInputStream.fill_async.io_priority default=GLib.Priority.DEFAULT BufferedInputStream.peek.offset default=0 // Possible GI bugs FileIOStream.seek.cancellable nullable FileInputStream.seek.cancellable nullable FileOutputStream.seek.cancellable nullable // Re-check these SimpleAsyncResult.new_take_error skip // Forward upstream AppLaunchContext .get_display.files type_arguments="File" .get_startup_notify_id.files type_arguments="File" ApplicationCommandLine.get_platform_data nullable DBusAnnotationInfo.annotations array DBusArgInfo.annotations array As you can see I skip it, but you are free to change its name of whatever. Either Gio-2.0.metadata inside the same directory of Gio-2.0.gir or use --metadatadir.
I don't understand Jiří's comment that this is just my experiment. Is valac not moving towards using gir files? I'm using a standard Gio-2.0.gir file distributed with girepository 1.0. From Luca's followup, it sounds like my options were to wait for valac to be fixed or to workaround it myself with a metadata file. Based on that, I'm reopening this for the valac fix. I don't understand why this was marked NOTABUG in the first place. I assumed that valac was hoping to be able to use gir files without any custom metadata provided by individual users of the compiler.
Vala is moving towards using GIRs but unfortunately Vala may never be able to do so without any further information, and this issue is a very good example of why. You may not like the fact that in Vala methods and named constructors are in the same namespace, but that doesn't mean it's a bug. Personally, I greatly prefer things the way they are. This is NOTABUG since Vala doesn't (yet) use GIR for generating the gio-2.0 VAPI. Once it does, Vala will also include the necessary metadata to get the VAPI generated correctly... there is already an equivalent line in the metadata file for use with GIDL (g_simple_async_result_new_take_error hidden="1"). If you want to generate a gio-2.0.vapi from GIR yourself, the correct solution would be to use a metadata file in your project.