We're calling g_object_notify so let's not make gobject to call it for
us.
This also allows to test that changing a property again doesn't lead to
dispatch properties being called.
This tests that we call a custom dispatch_properties_changed,
even in the absence of connected notify handlers. (A recent
optimization broke that and caused a regression in GTK).
When I optimized GObject to skip property notification
in some cases, I looked for whether the class has a
custom notify vfunc. I overlooked that that
dispatch_properties_changed can also be customized,
and if it is, we better not skip change notification.
This showed up as breakage in the adjustment tests
in the GTK testsuite.
Add tests in which `g_object_run_dispose()` is called on the source or target
of a `GBinding`. After commit a4fa456e67,
the target test caused a failed assertion in `g_weak_ref_set()` that was not
found by the existing tests. Commit 94ba14d542
weakens the assertion to allow the test to succeed.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2676
When weak references are being cleaned up, it is possible for the `qdata` for
both `quark_weak_locations` and `quark_weak_refs` to have been deallocated,
so that `g_datalist_id_get_data()` returns `NULL` for both. This happens
when `g_object_run_dispose()` is called for the target of a `GBinding`,
and is not an error.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2676
We should mention glib-mkenums in the documentation for
G_DEFINE_ENUM_TYPE and G_DEFINE_FLAGS_TYPE.
We should also mention the macros in the documentation for glib-mkenums.
This way, developers can choose the most appropriate tool for their use
case.
While you might want to use automated tools like glib-mkenums to
generate enumeration types for your library, it's often not entirely
necessary to complicate your build system in order to handle a couple of
enumerations with few values.
Just like we have G_DEFINE macros for object, interface, pointer, and
boxed types, we should provide macros for defining enum and flags types.
This makes calls to g_signal_connect_data() and g_signal_connect_object()
with default flags more self-documenting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes code that sets no flags a bit more self-documenting:
using G_TYPE_FLAG_NONE makes it clearer that no special behaviour is
required than literal 0, and clearer that there is no weird casting
between types than (GTypeFlags) 0.
GTypeFlags and GTypeFundamentalFlags occupy the same namespace and the
same bitfield, so I intentionally haven't added
G_TYPE_FUNDAMENTAL_FLAGS_NONE.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As with commit 0932f71460, which did this for refs/unrefs of the
object in `g_object_notify()`, we need to do a similar thing for
refs/unrefs of the instance with `g_signal_emit()`, for all the same
reasons.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Pass arguments to them so that they take minimal time. This will not
produce useful performance profiling results, but will smoketest that
the tests still run, don’t crash, and therefore probably aren’t
bitrotting too badly.
This is useful because a fair amount of work has gone into these
performance tests, and they’re useful every few years to analyse and
compare GObject performance. We don’t want them to bitrot between uses.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When running the test with `-s 0` it would previously crash. Fix that,
and make it so that it only does a single test run in that case.
This will be useful in an upcoming commit for smoketesting the test to
avoid bitrot.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is a partial revert of commit fa8c7c0da using the approach
suggested (and tested) by Kjell Ahlstedt.
It is intended to be temporary pending a proper dig into what’s causing
the regression, just so we can get the 2.73.1 release out.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2672
Coverity notices the `g_object_unref()` call in `g_object_notify()`, but
not the paired `g_object_ref()` call. It therefore incorrectly assumes
that every call to `g_object_notify()` frees the object. This causes a
lot (hundreds) of false positive reports about double-frees or
use-after-frees.
I can’t find a way to fix this using a model file, so the other options
are:
* Manually mark every report as a false positive and keep updating them
as the code changes over time. This would take a lot of maintainer
effort.
* Comment out the `g_object_ref()`/`g_object_unref()` calls when
running static analysis (but not in a normal production build). This
is ugly, but cheap and shouldn’t impact maintainability much.
So this commit implements option 2.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This prevents `-Wunused-function` warnings on platforms which don’t have
`HAVE_OPTIONAL_FLAGS` defined.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
g_object_new_with_custom_constructor needs to handle
freezing notifications in the same way as
g_object_new_internal.
Fixing a bug pointed out by Christian Hergert.
The corner-case we are handling here is that
we don't freeze the notify queue in g_object_init
(because there's no custom ->notify vfunc, but
then we gain a notify handler during instance
init, and instance init also triggers a
notification. Handle this by jit freezing
notification in g_object_notify_by_spec_internal.
Note that this is bad code - instance init really
shouldn't be doing things like this.
Testcase included.
Fixes: #2665
We need to match the conditions in g_object_init
for when we already have a freeze. Without that,
we underflow the freeze count and trigger a
warning.
Fixes: #2666
Beef up the singleton testcase to reproduce a
freeze count underflow when setting properties
at construction time, with a custom constructor.
Helps: #2666
