GNOME Bugzilla – Bug 604973
Generics + GObject-style construction error
Last modified: 2018-05-22 13:27:48 UTC
The following snippet causes gcc warnings on compilation, and then an assertion error for the GObject instance and a glibc invalid free() abort for the static string at runtime. class Foo<G> : GLib.Object { public G data { get; set; } public Foo(G v) { Object(data: v); } } void main() { new Foo<GLib.Object>(new GLib.Object()); // assertion new Foo<string>("toot"); // invalid free() }
This is invalid code as we cannot support GObject properties of generic types. The compiler should report an error, though.
Can't they represented as pointers?(In reply to comment #1) > This is invalid code as we cannot support GObject properties of generic types. > The compiler should report an error, though. They can be supported as pointers. The problem here is that g_dup_func is set after g_object_new. Instead, we should think to set those using g_object_new as first properties to be set. This would solve initialization of generic fields as well, like bug 523767.
Given how gtype constructs instances, these bugs aren't going to be fixed anytime soon. Should we move initialization of generic fields/properties in _construct rather than instance_init?
(In reply to comment #3) > Given how gtype constructs instances, these bugs aren't going to be fixed > anytime soon. Should we move initialization of generic fields/properties in > _construct rather than instance_init? That would make sense, it could also help fixing other access: class ObjectRef<G> { public class ref_type = typeof (G); // fails to compiler class construct { ref_type = typeof (G); // fails to compile } construct { ref_type = typeof (G); // invalid value as g_type is set later } }
Is not correct to initialize properties from a constructor using Object(), set it directly. Is not correct also to use generics, because its type are unknown. This code correct the problem: class Foo<G> : GLib.Object { public G data { get; set; } public Foo(G v) { data = v; } // set it directly } void main() { new Foo<GLib.Object>(new GLib.Object()); // assertion new Foo<string>("toot"); // invalid free() }
I was intending to report that the vala compiler does not diagnose this, but rather silently generates broken C code. If that is by design, I apologize for the noise.
(In reply to Benjamin Herr from comment #6) > I was intending to report that the vala compiler does not diagnose this, but > rather silently generates broken C code. If that is by design, I apologize > for the noise. We really apreciate your contribution, even in this kind of things. No noise is to point out issues you found. Changing this bug as enhancement, due to reported as invalid C code generation. May valac can scan constructors and throw an error when it founds an Object() call. On generics, we can detect use of this types on constructors and throw errors. Tagged for Vala 1.2.
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 Object() constructor use in wrong place.
Sounds good to me
-- 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/67.