GNOME Bugzilla – Bug 699956
Gtk.Dialog content area as Gtk.Box: assignment from incompatible pointer type
Last modified: 2013-05-10 19:49:09 UTC
Created attachment 243625 [details] Generated code from minimal example The following code: void main (string[] args) { Gtk.init (ref args); var a = new Gtk.Dialog (); a.get_content_area () as Gtk.Box; } when compiled with valac-0.20 gives me a "assignment from incompatible pointer type" warning. I've attached the generated c code - if you look at line 26, variable _tmp1_ is assigned a pointer of type GtkWidget* (see https://developer.gnome.org/gtk3/unstable/GtkDialog.html#gtk-dialog-get-content-area for the spec) But, _tmp1_ was declared a GtkBox*. Hence the warning. The way to fix this is by having valac ouput a (GtkBox*) case on line 26: _tmp1_ = gtk_dialog_get_content_area (a); should be corrected to: _tmp1_ = (GtkBox*) gtk_dialog_get_content_area (a); Possibly related bug: 611886
After discussion on IRC, it turns out that the annotation in gtk+-3.0.vapi: public class Dialog : Gtk.Window, Atk.Implementor, Gtk.Buildable { ... [CCode (type = "GtkWidget*")] public unowned Gtk.Box get_content_area (); is not actually being applied, hence the warnings.
Created attachment 243656 [details] [review] Resolves the bug for me but needs more testing. After perusing the code I think I found the correct place to add in the cast that's missing. I tested it out for the specific example I filed the bug for and it seems to work. Of course it needs more extensive testing but I am not familiar with the correct way to do this yet.
Created attachment 243665 [details] [review] Cast to correct type (fixes previous patch) Fixes inaccurate but harmless behavior in the previous patch. To be specific, the previous patch would cast the return value to the type of the return value - hence, doing absolutely nothing. The current patch casts to the proper return type that the caller is expecting. Note that an additional condition was added - only perform the cast if it is necessary (i.e. the return type differs). However, if the cast was unnecessary, then there shouldn't have been a [CCode type=] annotation in the first place.
Thanks for the patch, looks good. Are there any other places where CCode (type) is used in the vapis to test it?
There are many CCode (type) annotations all over the vapi, but this patch only applies to return vales. Most of these annotations apply to arguments. I found: https://git.gnome.org/browse/vala/tree/vapi/gio-2.0.vapi#n1537 But it is a return value of a constructor, which already works fine and is not covered by my patch. I didn't find any other places where a CCode (type) annotation applies to a return value that is not in a constructor. Just to be safe, I verified that the same C code is generated before and after applying my patch (when calling https://git.gnome.org/browse/vala/tree/vapi/gio-2.0.vapi#n1537). See my attached example.
Created attachment 243719 [details] testcase for PollableSource In the vapi, PollableSource has a [CCode type=] annotation for its return type. However, it is a constructor, so code generation should not be affected by my patch. To verify this, I used the attached test case.
commit 0d97c98734a8ad3504b114e55ccf8330ebaa4423 Author: Luca Bruno <lucabru@src.gnome.org> Date: Fri May 10 21:47:19 2013 +0200 codegen: Cast return values if [CCode (type)] is supplied Patch by avi.w.levy@gmail.com Fixes bug 699956. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.