When G_CLEANUP_SCOPE is defined the G_DEFINE_TYPE and macros
properly push newly registered GTypes onto the cleanup list.
In addition push all the the basic types into the libgobject
cleanup list.
https://bugzilla.gnome.org/show_bug.cgi?id=711778
Partially from patches from Ole André Vadla Ravnås, and Dan Winship
There are a lot of intertwined pointer references between
types, their vtables, and other bits. Free the memory for them
all together.
Note that we still do all finalization (ie: callbacks) per type
and module, in the relevant cleanup lists.
https://bugzilla.gnome.org/show_bug.cgi?id=711778
Rather than keeping a global list of objects that are being
constructed, use qdata on the object itself like we do with several
other properties now.
https://bugzilla.gnome.org/show_bug.cgi?id=661576
If a constructor() implementation created an object but then unreffed
it rather than returning it, that object would get left on the
construction_objects list, which would cause problems later when that
memory location got reused by another object.
"Fix" this by making it fail intentionally, and add a test for it (and
for the normal, working singleton case).
https://bugzilla.gnome.org/show_bug.cgi?id=661576
GBindingTransformFunc called its arguments "source_value" and
"target_value", but in the transform_from function of a bidirectional
binding, "source_value" comes from the target object, and
"target_value" comes from the source object, which quickly gets
confusing if you need to use g_binding_get_source(), etc, in the
function.
Of course developers can call their transform function arguments
whatever they want, but many will copy from the headers/docs to start
out, so use less confusing names here ("from_value" and "to_value").
Also, fix the documentation to describe the bidirectional case
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=709440
Add NULL check and return after calls to g_param_spec_internal in GParamSpec
creation functions. This avoids glib crashing due to things like badly named
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=707887
Apple's GCC compilers cannot deal well with 64-bit pointers in
transparent unions on ppc64, so compilation of
_G_DEFINE_BOXED_TYPE_BEGIN was failing. Fortunately glib already
provides a fallback for compilers that can't deal with it; this adds
this specific case to the check.
https://bugzilla.gnome.org/show_bug.cgi?id=647145
g_type_class_add_private() was doing
g_assert (node->data->instance.private_size <= 0xffff);
but that field is a guint16, so the check was a no-op. (Noticed by
clang, but not gcc for some reason.) Fix it to do the math in a gssize
variable and do the bounds checking there before updating the struct
field.
https://bugzilla.gnome.org/show_bug.cgi?id=706888
Convert {glib,gobject,gio}/tests to use the automake TAP driver
and test harness instead of gtester. To do so, we add a glib-tap.mk
that provides the same interface as glib.mk, except for the
reporting and coverage testing functionality. Eventually, we may
want to replace glib.mk with it. I've not yet converted the
toplevel tests/ directory, since it mixes gtestutils tests with
other binaries.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
Fix the warnings when compiling and linking the probes files by
calling dtrace with all the -W flags removed from CFLAGS (since dtrace
generates bad C code), and with CC set to "libtool --mode=compile ..."
(so that it will output a proper .lo file and libtool won't warn when
linking it into the .la).
https://bugzilla.gnome.org/show_bug.cgi?id=693335
Just like g_object_notify, check for a zero ref_count in
g_object_notify_by_pspec and leave if it is 0.
This allows using functions in ->finalize() that possibly also
notify a property change on the object. Previously,
this resulted in an error from g_object_ref.
https://bugzilla.gnome.org/show_bug.cgi?id=705570
We need a TypeName_private_offset variable defined by the macros used to
register dynamic types. We also need to call the adjust_private_offset()
function inside class_init(). G_ADD_PRIVATE_DYNAMIC only sets the size
of the private data structure, and relies on the behaviour of the
g_type_class_adjuset_private_offset() function to register the private
data structure at class init time if passed a value greater than zero.
This allows using G_PRIVATE_OFFSET with dynamic types.
Otherwise in e.g. the gnome-ostree integrationtest system, we
end up sending SIGUSR1 to the *entire session*, which triggers
various badness in untested debugging paths from gnome-session.
This test worked when compiled without optimization, but fails with
-O2. Presumably we just happened to find the GMainLoop off the stack
somewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=704267
GPid is a HANDLE (aka void *) on Windows, not an int, so treat pid
accordingly on Windows, as using pid as a gulong directly would likely be
undesirable on Windows
https://bugzilla.gnome.org/show_bug.cgi?id=704447
- Mention G_SOURCE_CONTINUE and G_SOURCE_REMOVE in the GSourceFunc doc;
- Mention G_PARAM_READWRITE and G_PARAM_STATIC_STRINGS in the
GParamFlags doc;
- Fix "Since:" version for G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE;
- Fix typo.
https://bugzilla.gnome.org/show_bug.cgi?id=704250
For the glib-defined source types, and any source type that defines a
closure callback but not a closure marshal, use
g_cclosure_marshal_generic. And then remove all the other remaining
source closure marshals.
https://bugzilla.gnome.org/show_bug.cgi?id=701511
When using the GLIB_VERSION_MAX_ALLOWED macro to define the upper bound
of allowed API the G_DEFINE_TYPE_EXTENDED starts warning about the newly
added g_type_class_adjust_private_offset() function; this effectively
introduces a run-time dependency on GLib 2.38 even if we don't use its
API explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=703191
As it turns out, we have examples of internal functions called
type_name_get_private() in the wild (especially among older libraries),
so we need to use a name for the per-instance private data getter
function that hopefully won't conflict with anything.
