GNOME Bugzilla – Bug 523767
Generics don't work in field initializers
Last modified: 2018-05-22 13:04:45 UTC
Please describe the problem: when defining a generic class MyClass<G>, and defining a signal for this class void my_signal(G); the signal gets a VOID__POINTER marshaler, this works well, until you pass a GObject that is about to be unreffed, in which case the Object is lost. Vala should maybe avoid unreffing the Object in such cases ? Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
I don't understand when a GObject gets freed too early in this case, can you explain?
Created attachment 107865 [details] test case
Comment on attachment 107865 [details] test case This is a small test case showing the behavior of generics with signals
Thanks for the test case. I can see the issue, however, it's completely unrelated to signals, as far as I can tell. The problem is that you create a generic ArrayList in the field initializer. The generic type information is not available yet in instance_init which means that the array list won't use g_object_ref when adding an object to the list. We need to perform the following changes: * Never try to use generic type information in instance_init, either disallow or move to constructor in generated C code * Mark generic type properties as construct properties and make sure to initialize them appropriately (as part of the g_object_newv call instead of directly accessing the private fields)
ok thanks, doing a lazy construction of the ArrayList solves the problem
The second point has been fixed some time ago in bug 528567
Created attachment 244697 [details] [review] Warn for generic initializers on static and class fields Warn for generic initializers on static and class fields since the generic type is only known at the end of the object construction. The generic type is not known in *_base_init or *_class_init.
I was just burned by this bug. It would be great if this issue could be addressed or Geert's patch reviewed. A compiler warning would've saved me a lot of headache. However, I'm confused: Geert's patch seems to warn for static/class fields, but the issue, if I understand Jürg's comment in #4, is for instance fields. That's certainly the problem I've encountered. I've constructed a simple test case (which I'll attach) that demonstrates the problem. It would be helpful if the warning was for all three, or better yet, this problem was resolved.
Created attachment 274723 [details] Simple test case of problem
Created attachment 345068 [details] [review] Patch to make this throw an error I modified the existing attached patch. I changed it from warning to error. I made this choice since the issue still isn't fixed. I'd gladly change it back to warning if that gets the patch accepted.
I think this is an issue to use Vala Generics in wrong place. Vala Generics are powerful tool and should be improved in many ways, I really discourage its use in public API, if you want clean easy to use C API and Introspectable. I use Gee in lot of places in GXml and have lot of issues here and there, I will share you, but again try don't use Generics outside of properties no in signals and just internals, at least for now. As a work around, pass an Object with a property of using Generics, then it will be used as any object. At signal handling get object's property and use your Generic as you need, As there are workarounds, I've downgrade its severity to enhancement and tagged to Vala 2.0. May create a Bug for "Improve Vala Generics" could be good.
Please confirm this can be marked as Normal-Enhancement, because is a bug with a workaround and can be fixed by user. Is an enhancement because Vala can rise errors detecting generics use in wrong place. I've keeped tag for 2.0 milestone.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/5.