GNOME Bugzilla – Bug 539969
Generated code contains errors when using HashMap and SequenceIter
Last modified: 2008-09-26 19:38:16 UTC
$ valac --pkg gee-1.0 -o test test.vala test.c: In function 'test_constructor': test.c:146: error: expected expression before ')' token error: cc exited with status 256 Compilation failed: 1 error(s), 0 warning(s)
Created attachment 113337 [details] Test case
Similar error when using SList<SequenceIter<K>>
Confirming.
Reduced test case: [Compact] [CCode (ref_function = "", unref_function = "")] class Foo { } class Bar<X> { } void main () { var e = new Bar<Foo> (); } Removing the CCode attribute from Foo makes vala complain about copying and suggests changing to 'new Bar<weak Foo>'. Adding the 'weak' results in correct C code regardless of whether the CCode attribute or not. I don't really understand how the generics code works, but the above testing indicates to me that the test case should result in a vala error complaining about the lack of ref and unref functions. Jürg/Raffaele, does this sound correct? Sebastian, is it possible to make your code work with 'weak SequenceIter<K>' ?
Created attachment 114578 [details] [review] maybe fix? Attached patch makes vala produce an error for this test case. Also, SequenceIter seems to be the only class in all the Vala bindings with ref_function = "", so maybe that is also incorrect? $ grep "ref_function *= *\"\"" vapi/*.vapi
Created attachment 114628 [details] More extensive test case I applied your patch. The code compiles and works for me. However, I still get a warning: warning: passing argument 3 of 'g_sequence_insert_sorted' from incompatible pointer type I attached a more extensive test case.
Ok, cool. The problem there is that the generated function static gint _number_compare_gcompare_data_func (void* a, void* b, gpointer self) { return number_compare (a, b); } should have 'const void *' in order to be a GCompareDataFunc. But that is fairly harmless. There are already a few bugs filed about not using 'const' in generated methods, I'm not sure if this problem is a dupe of one of those or a different issue.
The ref_function = "" and all the weak SequenceIter were a workaround to avoid memory management for these instances. I'll commit a change to bind SequenceIter as a value-type, which should fix the issue.
2008-09-26 Jürg Billeter <j@bitron.ch> * vapi/glib-2.0.vapi: Fix GSequenceIter binding, it should be treated as a value-type, fixes bug 539969 Fixed in r1784.