Commit Graph

438 Commits

Author SHA1 Message Date
Thomas Haller
7b9e6d4949 tests/performance: add "refcount-toggle" test
Performance test for emitting toggle reference notifications.
2024-03-18 13:56:03 +00:00
Thomas Haller
2b1a7e30b1 tests/performance: avoid check for toggle notification in "property-{get,set}"
Bumping the reference count from 1 to 2 (and back) is more expensive,
due to the check for toggle notifications.

We have a performance test already that hits that code path. Avoid that
for he "property-{get,set}" tests, so we avoid the known overhead and
test more relevant parts.
2024-03-18 13:56:02 +00:00
Thomas Haller
b6789dd1ea tests/performance: add "refcount-1" test
When an object has ref-count 1, then calling g_object_ref() requires a
check for toggle references. That is slower. Add a test for that case.
2024-03-18 13:56:02 +00:00
Thomas Haller
282d536fd2 tests/performance: ensure to always warm up for 2 seconds
Despite all the efforts, there still seems to be a lot of noise in the
performance measurement. Especially, the first iterations seem to run
faster. Maybe that is because the kernel didn't yet determine that the
process is CPU bound and is less likely to schedule it out Or maybe it's
because burning the cycles heats up the CPU and it gets throttled after
a while. It's unclear why, and it's even unclear whether this really
happens. But from my observations, it seems to do.

Hence, more warm up.

- the first time we enter the test, ensure that we keep the CPU busy for
  at 2 seconds. This additional warm up (WARM_UP_ALWAYS_SEC) is
  global, and not per test.

- for each test, ignore the first 5% of the runs. It seems those tend to
  run faster, thus skewing the results.

- if the user specifies a "--factor", the warm up operations are the
  same and independent from external factors (such as time
  measurements).

Note that this matters the most, when you want to run the executable
twice in a row and compare the results.
2024-03-18 13:56:02 +00:00
Thomas Haller
29a69d5a1b tests/performance: add "factor" argument to performance test
By default, the test estimates a run factor for each test. This means,
if you run performance under `perf`, the results are not comparable,
as the run time depends on the estimated factor.

Add an option, to set a fixed factor.

Of course, there is only one factor argument for all tests.  Quite
possibly, you would want to run each test individually with a factor
appropriate for the test. On the other hand, all tests should be tuned
so that the same factor gives a similar test duration. So this may not
be a concern, or the tests should be adjusted. In any case, the option
is most useful when running only one test explicitly.

You can get a suitable factor by running the test once with "--verbose".

Another use case is if you run the benchmark under valgrind. Valgrind
slows down the run so much, that the estimated factor would be quite
off. As a result, the chosen code paths are different from the real run.
By setting the factor, the timing measurements don't affect the executed
code.
2024-03-18 13:56:02 +00:00
Thomas Haller
e5e3c37d22 tests/performance: add "--quiet" argument to performance
The default output is annoyingly verbose. You see

  Running test simple-construction
  simple-construction: Millions of constructed objects per second: 33.498
  Running test simple-construction1
  simple-construction1: Millions of constructed objects per second: 142.493
  Running test complex-construction
  complex-construction: Millions of constructed objects per second: 14.304
  Running test complex-construction1
  ...

where the "Running test" lines just clutter the output. In fact so much
so, that my terminal fills up and I don't see the output of all tests in
one page. The "Running test" line is not so useful, because I mostly
care about the test result, and that line already contains the test
name.

Add an option to silence this.
2024-03-18 13:56:02 +00:00
Thomas Haller
65a59bde57 tests/performance: print result in unique line
Previously, the result lines are not unique, for example

  Running test simple-construction
  Millions of constructed objects per second: 27.629
  Running test simple-construction1
  Millions of constructed objects per second: 151.879
  ...

That is undesirable, because we might want to parse the test results
with a script, and that's easier when the line is unique.

Change to:

  Running test simple-construction
  simple-construction: Millions of constructed objects per second: 27.629
  Running test simple-construction1
  simple-construction1: Millions of constructed objects per second: 151.879
  ...
2024-03-18 13:56:02 +00:00
Philip Withnall
3c39a23a7e tests: Speed up threaded toggle notify test unless -m slow is passed
On a fast laptop, this test currently takes about 7s to run, which is a
significant portion of the overall test suite time.

On a slower CI machine, especially running the test under valgrind, the
test can time out.

There’s no need to always run so many iterations: we run the tests under
CI so often that it’s likely a failure will eventually be hit (if there
is a bug) even with fewer iterations. We also now run the tests once a
week with `-m slow`, so the original iteration count will also still be
used then.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-02-13 08:52:15 +00:00
Philip Withnall
5f6b1516ae tests: Rework how slow param test is skipped
It’s more helpful to always register the test, even if it’s normally
skipped, since then the skip is recorded in the test logs so people can
see what’s ‘missing’ from them.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-02-06 11:01:46 +00:00
Philip Withnall
3f4e6ddcd8 Merge branch 'thorough-tests-in-ci' into 'main'
build: Add thorough test setup

See merge request GNOME/glib!3838
2024-02-02 14:33:22 +00:00
Thomas Haller
d8e4f39aa8 gobject: track GWeakRef in object's WeakRefData with an array
GSList doesn't seem the best choice here. It's benefits are that it's
relatively convenient to use (albeit not very efficient) and that an
empty list requires only the pointer to the list's head.

But for non-empty list, we need to allocate GSList elements. We can do
better, by writing more code.

I think it's worth optimizing GObject, at the expense of a bit(?) more
complicated code. The complicated code is still entirely self-contained,
so unless you review WeakRefData usage, it doesn't need to bother you.
Note that this can be easily measure to be a bit faster. But I think the
more important part is to safe some allocations. Often objects are
long-lived, and the GWeakRef will be tracked for a long time. It is
interesting, to optimize the memory usage of that.

- if the list only contains one weak reference, it's interned/embedded in
  WeakRefData.list.one. Otherwise, an array is allocated and tracked
  at WeakRefData.list.many.

- when the buffer grows, we double the size. When the buffer shrinks,
  we reallocate to 50% when 75% are empty. When the buffer shrinks to
  length 1, we free it (so that "list.one" is always used with a length
  of 1).
  That means, at worst case we waste 75% of the allocated buffer,
  which is a choice in the hope that future weak references will be
  registered, and that this is a suitable strategy.

- on architectures like x86_68, does this not increase the size of
  WeakRefData.

Also, the number of weak-refs is now limited to 65535, and now an
assertion fails when you try to register more than that. But note that
the internal tracking just uses a linear search, so you really don't
want to register thousands of weak references on an object. If you do
that, the current implementation is not suitable anyway and you must
rethink your approach. Nor does it make sense to optimize the
implementation for such a use case. Instead, the implementation is
optimized for a few (one!) weak reference per object.
2024-02-02 14:49:09 +01:00
Thomas Haller
824c4da44b gobject/tests: add test that creates a large number of weak references
The implementation of GWeakRef tracks weak references in a way, that
requires linear search. That is probably best, for an expected low
number of entries (e.g. compared to the overhead of having a hash
table). However, it means, if you create thousands of weak references,
performance start to degrade.

Add a test that creates 64k weak references. Just to see how it goes.
2024-02-02 14:49:09 +01:00
Thomas Haller
970325b92d gobject/tests: add test checking that GWeakRef is cleared in GWeakNotify
g_object_weak_ref() documentation refers to GWeakRef as thread-safe
replacement.  However, it's not clear to me, how GWeakRef is a
replacement for a callback. I think, it means, that you combine
g_object_weak_ref() with GWeakRef, to both hold a (thread-safe) weak
reference and get a notification on destruction.

Add a test, that GWeakRef is already cleared inside the GWeakNotify
callback.
2024-01-31 12:42:02 +01:00
Philip Withnall
a4b9b41afc tests: Fix a double-free in param test
This isn’t normally hit because it’s in a test which is disabled unless
run with `-m thorough`.

The data is owned by `g_test_add_data_func_full()` until the end of the
process.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-01-18 17:22:09 +00:00
Philip Withnall
d738dcc76f tests: Fix an expected message in param test
This isn’t normally hit because it’s in a test which is disabled unless
run with `-m thorough`.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-01-18 17:22:09 +00:00
Philip Withnall
5d38f3ebd4 tests: Fix a double-unref in params tests
This isn’t normally hit because it’s in a test which is disabled unless
run with `-m thorough`.

The `GParamSpec` is initially floating, but its floating ref is sunk by
`g_object_interface_install_property()` (regardless of whether that call
succeeds or aborts). The behaviour of
`g_object_interface_install_property()` in this respect may have changed
more recently than the test was written.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-01-18 17:22:09 +00:00
Thomas Haller
5609370de9 gbitlock: add g_pointer_bit_lock_and_get()
Usually, after g_pointer_bit_lock() we want to read the pointer that we
have. In many cases, when we g_pointer_bit_lock() a pointer, we can
access it afterwards without atomic, as nobody is going to modify the
pointer then.

However, gdataset also supports g_datalist_set_flags(), so the pointer
may change at any time and we must always use atomics to read it. For
that reason, g_datalist_lock_and_get() does an atomic read right after
g_pointer_bit_lock().

g_pointer_bit_lock() can easily access the value that it just set. Add
g_pointer_bit_lock_and_get() which can return the value that gets set
afterwards.

Aside from saving the second atomic-get in certain scenarios, the
returned value is also atomically the one that we just set.
2024-01-16 12:50:31 +01:00
Thomas Haller
c4c76d77cb gbitlock: add g_pointer_bit_unlock_and_set() and g_pointer_bit_lock_mask_ptr()
The existing g_pointer_bit_lock() and g_pointer_bit_unlock() API
requires the user to understand/reimplement how bits of the pointer get
mangled. Add helper functions for that.

The useful thing to do with g_pointer_bit_lock() API is to get/set
pointers while having it locked. For example, to set the pointer a user
can do:

    g_pointer_bit_lock (&lockptr, lock_bit);
    ptr2 = set_bit_pointer_as_if_locked(ptr, lock_bit);
    g_atomic_pointer_set (&lockptr, ptr2);
    g_pointer_bit_unlock (&lockptr, lock_bit);

That has several problems:

- it requires one extra atomic operations (3 instead of 2, in the
  non-contended case).

- the first g_atomic_pointer_set() already wakes blocked threads,
  which find themselves still being locked and needs to go back to
  sleep.

- the user needs to re-implement how bit-locking mangles the pointer so
  that it looks as if it were locked.

- while the user tries to re-implement what glib does to mangle the
  pointer for bitlocking, there is no immediate guarantee that they get
  it right.

Now we can do instead:

  g_pointer_bit_lock(&lockptr, lock_bit);
  g_pointer_bit_unlock_and_set(&lockptr, lock_bit, ptr, 0);

This will also emit a critical if @ptr has the locked bit set.
g_pointer_bit_lock() really only works with pointers that have a certain
alignment, and the lowest bits unset. Otherwise, there is no space to
encode both the locking and all pointer values. The new assertion helps
to catch such bugs.

Also, g_pointer_bit_lock_mask_ptr() is here, so we can do:

  g_pointer_bit_lock(&lockptr, lock_bit);
  /* set a pointer separately, when g_pointer_bit_unlock_and_set() is unsuitable. */
  g_atomic_pointer_set(&lockptr, g_pointer_bit_lock_mask_ptr(ptr, lock_bit, TRUE, 0, NULL));
  ...
  g_pointer_bit_unlock(&lockptr, lock_bit);

and:

  g_pointer_bit_lock(&lockptr, lock_bit);
  /* read the real pointer after getting the lock. */
  ptr = g_pointer_bit_lock_mask_ptr(lockptr, lock_bit, FALSE, 0, NULL));
  ...
  g_pointer_bit_unlock(&lockptr, lock_bit);
2024-01-16 12:16:42 +01:00
Thomas Haller
e05623001b gobject: fix deadlock with g_weak_ref_set()
In general, we must not call out to external, unknown code while holding
a lock. That is prone to dead lock.

g_object_ref() can emit a toggle notification. In g_weak_ref_set(), we
must not do that while holding the lock.
2024-01-04 16:42:59 +01:00
Thomas Haller
6c389738d3 gobject/tests/reference: add tests for concurrent g_weak_ref_set()
GWeakRef methods are thread safe. Add test for calling g_weak_ref_set()
concurrently.
2024-01-04 16:32:09 +01:00
Thomas Haller
787861761d gobject/tests/reference: add test for deadlock related to GWeakRef and toggle reference
GWeakRef calls g_object_ref() while holding a read lock.
g_object_ref() can emit a toggle notification.

If you then inside the toggle notification setup a GWeakRef
(to the same or another object), the code will try to get
a write lock. Deadlock will happen.

Add a test to "show" that (the breaking part is commented out).
Will be fixed next.
2024-01-04 16:17:13 +01:00
Philip Withnall
dd2b6d7e3f Merge branch 'th/g-object-unref-ref' into 'main'
[th/g-object-unref-ref] fix race in g_object_unref()

Closes #3064

See merge request GNOME/glib!3769
2024-01-03 23:39:24 +00:00
Philip Withnall
bf7ccbde9e tests: Fix a minor leak in the new GParamSpecPool test
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2024-01-03 12:04:16 +00:00
Tanmay
dbbd9c60ba Add boxed GType for GRand
Signed-off-by: Tanmay Patil <tanmaynpatil105@gmail.com>
2023-12-31 09:09:48 +00:00
Thomas Haller
2952cfd7a7 gobject: drop clearing quark_weak_locations from g_object_real_dispose()
In g_object_unref(), we call _object_unref_clear_weak_locations() before
and after dispose() already. At those places it is necessary to do.

Calling it a third time during g_object_real_dispose() seems not useful,
has unnecessary overhead and actually undesirable.

In particular, because g_object_real_dispose() is the implementation for
the virtual function GObject.dispose(). For subclasses that override dispose(),
it's not well defined at which point they should chain up the parent
implementation (for dispose(), I'd argue that usually they chain up at
the end of their own code). If they chain up at the end, this has no
effect.

This only really matters if you try to register GWeakRef during dipose
and/or resurrect the object.

        static void dispose(GObject *object)
        {
            g_weak_ref_set(&global_weak_ref, object);
            global_ref = g_object_ref(object);
            G_OBJECT_CLASS (parent_class)->dispose (object);
        }

the object was resurrected, but g_object_real_dispose() would clear the
weak ref. That is not desirable, nor does it make sense.

Instead, the virtual function dispose() is called from two places, from
g_object_unref() and g_object_run_dispose(). In both cases, it is
ensured that weak locations are cleared *after* dispatching the virtual
function. Don't do it somewhere in the middle from
g_object_real_dispose().
2023-12-30 00:20:17 +01:00
Thomas Haller
408dc69186 gobject: fix race in g_object_unref() related to toggle references
The previous g_object_unref() was racy. There were three places where we
decremented the ref count, but still accessed the object afterwards
(while assuming that somebody else might still hold a reference). For
example:

      if (!g_atomic_int_compare_and_exchange_full ((int *) &object->ref_count,
                                                   old_ref, old_ref - 1,
                                                   &old_ref))
        continue;

      TRACE (GOBJECT_OBJECT_UNREF (object, G_TYPE_FROM_INSTANCE (object), old_ref));

      /* if we went from 2->1 we need to notify toggle refs if any */
      if (old_ref == 2 && OBJECT_HAS_TOGGLE_REF (object))
        {
          /* The last ref being held in this case is owned by the toggle_ref */
          toggle_refs_notify (object, TRUE);
        }

After we decrement the reference count (and gave up our reference), we
are only allowed to access object if we know we have the only possible
reference to it. In particular, if old_ref is larger than 1, then
somebody else holds references and races against destroying object.
The object might be a dangling pointer already.

This is slightly complicated due to toggle references and clearing of
weak-locations.

For toggle references, we must take a lock on the mutex. Luckily, that
is only necessary, when the current reference count is exactly 2.

Note that we emit the TRACE() after the ref count was already decreased.
If another thread unrefs the object, inside the TRACE() we might have a
dangling pointer. That would only be fixable, by emitting the TRACE()
before the actual unref (which has its own problems). This problem
already existed previously.

The change to the test is necessary and correct. Before this patch,
g_object_unref() would call dispose() and decrement the reference count
right after.
In the test case at gobject/tests/reference.c:1108, the reference count
after dispose and decrement is 1. Then it thaws the queue notification,
which emits a property changed signal. The test then proceeds to
reference the object again and notifying the toggle reference.
Previously, the toggle reference was notified 3 times.
After this change, the property changed signal is emitted before
decreasing the reference count. Taking a reference then does not cause
an additional toggle on+off, so in total only one toggle happens.
That accounts for the change in the test. The new behavior is
correct.
2023-12-28 09:36:56 +01:00
Emmanuele Bassi
4a270c947c tests: Check thread safety of GParamSpecPool
Aside from checking that we're accessing the global GParamSpecPool
without necessarily initializing GObjectClass, we should also verify
that we're doing so safely without the class init lock.
2023-12-19 22:48:03 +00:00
Emmanuele Bassi
62477118e7 tests: Verify GParamSpecPool creation
Ensure that the fix in commit af024b6d7e7d3fbef23c1f7d1f7704fc90ac4fb1
works, by replicating what gobject-introspection does:

- initialise the default GTypeInterface from a GType without also
  initialising GObjectClass
  - install a property for the interface
- find the GParamSpec using g_object_interface_find_property()
2023-12-19 19:53:48 +00:00
Emmanuele Bassi
540ba432fb tests: Add unit for GParamSpecPool
Check that the API contract is respected, even though nobody should be
using GParamSpecPool to implement properties outside of GObject.
2023-12-19 19:53:48 +00:00
Lukáš Tyrychtr
a473d5aea0 mkenums: Allow , in a character literal
This required adding a higher precedence character literal choice.

Fixes #3103
2023-11-21 11:54:42 +00:00
Philip Withnall
e87f8e9c5a Merge branch '3158-info-critical' into 'main'
gio-tool-info: Fix critical warning when --attributes are specified and add basic unit tests

Closes #3158

See merge request GNOME/glib!3684
2023-11-07 14:37:11 +00:00
Philip Withnall
077104e63b tests: Run processes under test with G_DEBUG=fatal-warnings
Modify all the similar Python test wrappers to set
`G_DEBUG=fatal-warnings` in the environment of the program being tested,
so we can catch unexpected warnings/criticals.

Adding this because I noticed it was missing, not because I noticed a
warning/critical was being ignored.

Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
2023-11-07 13:51:56 +00:00
Alexander Slobodeniuk
7880d87091 gvalue: add g_value_steal_string()
This call is needed to avoid an extra copy after
serialization of the data.
2023-11-04 10:40:30 +00:00
Kleis Auke Wolthuizen
9ec6c19342 gsignalgroup: Avoid function call with side effect in g_return_* macro 2023-11-01 10:53:55 +00:00
Damien Zammit
f25a9ca10c Initial test of Hurd CI - (run_tests.sh status ignored) 2023-10-18 23:33:04 +00:00
Alex Richardson
5ecd3cbe52 gobject: use g_once_init_enter_pointer for GType initializers
GType is either an integer or a pointer, so we have to use the _pointer
version here to support architectures such as Morello.

Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
See also: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3578
2023-10-04 14:50:54 +01:00
Christian Hergert
eb8a33625e gobject: Separate GWeakRef from GWeakNotify
This patch is based upon Garrett Regier's work from 2015 to provide
some reliability and predictability to how disposal handles weak
reference state.

A primary problem is that GWeakRef and GWeakNotify state is shared and
therefore you cannot rely on GWeakRef status due to a GWeakNotify
calling into second-degree code.

It's important to ensure that both weak pointer locations and GWeakRef
will do the proper thing before user callbacks are executed during
disposal. Otherwise, user callbacks cannot rely on the status of their
weak pointers. That would be mostly okay but becomes an issue when
second degree objects are then disposed before any notification of
dependent object disposal.

Consider objects A and B.

`A` contains a reference to `B` and `B` contains a `GWeakRef` to `A`.
When `A` is disposed, `B` may be disposed as a consequence but has not
yet been notified that `A` has been disposed. It's `GWeakRef` may also
cause liveness issues if `GWeakNotify` on `A` result in tertiary code
running which wants to interact with `B`.

This example is analagous to how `GtkTextView` and `GtkTextBuffer` work
in text editing applications.

To provide application and libraries the ability to handle this using
already existing API, `GWeakRef` is separated into it's own GData quark
so that weak locations and `GWeakRef` are cleared before user code is
executed as a consequence of `GData` cleanup.

# Conflicts:
#	gobject/tests/signals.c
2023-08-25 14:25:47 -07:00
Philip Withnall
c2df874e0b tests: Add some more tests for g_type_query()
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-07-30 13:51:00 +03:00
Philip Withnall
d9b23c5466 gtype: Allow g_type_query() to be called on dynamic types
There’s no reason that anyone can think of that this should be
disallowed. It’s useful for language runtimes like GJS to be able to
find out the allocation size of dynamic GObjects.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Fixes: #623
2023-07-30 11:25:42 +03:00
Chun-wei Fan
cb1eb57581 gobject tests: Fix running custom-dispatch on 32-bit Windows
UAC will terminate this test program from running in 32-bit x86 builds as
it believes that it will alter Windows.  In order to make this run, we
create a manifest file for 32-bit Windows builds in order to tell UAC
that this program should not need admin privileges.

This will allow the entire test suite for GLib to run on 32-bit Windows
builds.
2023-06-30 11:32:54 +08:00
Philip Withnall
5c50aec060 Merge branch 'glib-mkenums_parse_trigraph' into 'main'
Take double-quote characters into account when parsing trigraph

Closes #65

See merge request GNOME/glib!3452
2023-05-30 14:45:54 +00:00
Emmanuel Fleury
7e5607d534 Take double-quote characters into account when parsing trigraph
For now, the function parse_trigraph() defined in gobject/glib-mkenums
script was not taking double-quotes characters into account:

>>> parse_trigraph('name="eek, a comma"')
{'name': '"eek', 'a': None}

This patch take double-quotes characters into account:

>>> parse_trigraph('name="eek, a comma"')
{'name': 'eek, a comma'}

Closes issue #65
2023-05-30 15:22:05 +02:00
Marco Trevisan (Treviño)
bfc599b8a2 gsignal: Reduce lock/unlock operations when calling signal_emit_unlocked_R
We used to call this function as unlocked, with a node value that
could be invalid at the point of the call, so let's ensure that when
we call such function it's defined, and then reduce the access to the
signal node members when we're unlocked or after a lock/unlock operation
that may have changed it.

As per this, add more tests handling multiple signal hooks cases that we
did not cover before.
2023-05-30 13:52:08 +01:00
Marco Trevisan (Treviño)
0bc725d4fe gobject/tests/signals: Add tests for g_object_emitv
It's very much used by bindings but we didn't really test it locally.
2023-05-30 13:52:07 +01:00
Eric Blake
2ab2ce57e6 gtestutils: Improve g_assert_cmpuint
While x86_64 has enough precision in long double to do a round trip
from guint64 to long double and back, this is platform-specific, and
is a disservice to users trying to debug failing unit tests on other
architectures where it loses precision for g_assert_cmp{int,uint,hex}.
See also https://bugzilla.gnome.org/show_bug.cgi?id=788385 which
mentions having to add casts to specifically silence the compiler on
platforms where the precision loss occurs.

Meanwhile, g_assert_cmpuint() does an unsigned comparison, but outputs
signed values if the comparison fails, which is confusing.

Fix both issues by introducing a new g_assertion_message_cmpint()
function with a new 'u' numtype.  For backwards compatibility, the
macros still call into the older g_assertion_message_cmpnum() when not
targetting 2.78, and that function still works when passed 'i' and 'x'
types even though code compiled for 2.78 and later will never invoke
it with numtype anything other than 'f'.  Note that g_assert_cmpmem
can also take advantage of the new code, even though in practice,
comparison between two size_t values representing array lengths that
can actually be compiled is unlikely to have ever hit the precision
loss.  The macros in signals.c test code does not have to worry about
versioning, since it is not part of the glib library proper.

Closes #2997
Signed-off-by: Eric Blake <eblake@redhat.com>
2023-05-09 08:28:09 -05:00
Przemyslaw Gorszkowski
74d49e447f Test g_signal_handlers_disconnect_matched for G_SIGNAL_MATCH_ID match
Signed-off-by: Przemyslaw Gorszkowski <pgorszkowski@igalia.com>
2023-04-18 12:50:55 +02:00
Przemyslaw Gorszkowski
b264585f3c gsignal: Support G_SIGNAL_MATCH_ID in g_signal_handlers_block/unblock/disconnect_matched()
Calling g_signal_handlers_block/unblock/disconnect_matched with only G_SIGNAL_MATCH_ID
do not match any handlers and return 0.

Fixes: #2980

Signed-off-by: Przemyslaw Gorszkowski <pgorszkowski@igalia.com>
2023-04-14 15:27:11 +01:00
Philip Withnall
2d8e38c00d gsignal: Clarify documentation for GSignalMatchType matching
The use of ‘OR’ in the existing documentation suggests that the matching
is disjunctive, but it’s actually conjunctive. Clarify that in the
documentation and add a test.

Spotted while reviewing
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3376.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-04-14 13:55:20 +01:00
Philip Withnall
d1eb9c840c tests: Add type flag tests for interfaces
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #252
2023-04-13 15:39:37 +01:00
Philip Withnall
3d7e88a77d build: Drop old .gitignore files from test directories
They just listed built files. Since the move to Meson, these are all
kept in a separate build directory, not the source tree, so don’t need
to be ignored.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-03-20 12:09:02 +00:00