This brings its naming more in line with modern GLib conventions.
This is an API break, but libgirepository is not API frozen yet.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This test case was originally written by Philip Chimento as a reproducer
for #3218. Let’s add it to the test suite to catch regressions in
stack-allocated `GIBaseInfo` handling.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3218
Most of the code for handling stack-allocated infos was correct, it was
just missing code to initialise the `GTypeInstance` member.
Since `GTypeInstance` isn’t really designed for stack allocation, this
is a little hacky — it requires setting up the member within
`GTypeInstance` manually. It works, though.
The externally visible consequence of this, though, is that
stack-allocated `GIBaseInfo`s now need to be cleared when they’re
finished being used. This allows the `GTypeClass` ref to be dropped.
All users of the stack-allocated APIs in libgirepository will need to
adapt to this change.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3218
This is one more step towards removing `GIInfoType`, and will also help
in a following commit which will directly make use of the `GType`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3218
As documented in the commit, the internal members of `GIBaseInfo` are
not reffed if the `GIBaseInfo` is stack-allocated, as the caller can be
relied on to ensure their lifetime exceeds that of the `GIBaseInfo`.
Make sure that’s actually reflected in the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3218
Make it take a `GITypeInfo` rather than a `GIBaseInfo`, because that’s
what it actually operates on.
This is an internal API, so this isn’t an API break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3218
This fixes a race condition which frequently caused the
`memory-monitor-dbus.py` test to fail.
The registration of the `LowMemoryMonitor` object on the bus, and the
`GMemoryMonitorDBus`’s connection to the warning signal raced, such that
it was possible for the mock `LowMemoryMonitor` to emit a warning signal
before the `GMemoryMonitorDBus` proxy was listening, and hence the proxy
would never see the signal.
Fix this by explicitly synchronising the two before proceeding to the
tests.
Make the same changes in the `memory-monitor-portal.py` test too, even
though that one was not failing. This should remove the need for a 2s
wait on every test run.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #2887
Otherwise the test can go on to wait for a signal from the service
before it’s actually finished starting up.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #2887
Rather than sleeping and blocking everything, use a timeout source on
the main context so that inputs can continue to be handled while waiting
for a timeout.
This introduces no functional changes to the test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #2887
It should be doing already (or the tests would never work), but make it
clearer in the code that the same `GMainContext` is being iterated as is
being woken up in the rest of the test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #2887
When linking static libraries, multiple resources is an error unless
handled in a special way. glib and gobject do not have this problem,
as they already only include resources when building a shared lib.
This removes the gthash utility functions from the ABI, so link those
into their automated test statically.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Saying that a GtkWidget is a GtkWidget is trivially true, but not the
point we were trying to make here.
Fixes: b5c07063 "docs: Use code for class names in links"
Signed-off-by: Simon McVittie <smcv@collabora.com>
Merge it with the `G_DISABLE_ASSERT` test run, to avoid tying up another
test runner for no particular benefit.
By running the thorough tests regularly, we’ll hopefully avoid them
atrophying again (see the previous few commits full of fixes to them).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This allows the tests to be run with `meson test --setup thorough` and
it will run all the GTest tests with `-m thorough`.
Since this argument isn’t supported by the Python tests, it’s not passed
to them.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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>
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>
The test cancellation timeout was being tested twice, once only when run
with `-m thorough`. Seems a bit pointless.
Merge the two tests and use the smaller timeout values from the two, so
the test suite doesn’t run any more slowly than it did.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`g_test_init()` needs to be called before custom command line handling
so it has a chance to strip out the arguments it handles.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This avoids four coredumps being processed for every run of the
`testing` unit tests (which test `GTest`).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
I ran Bustle/dbus-monitor on the session bus while running the full GLib
test suite, and noticed that these tests were causing `Launched` signal
emissions on the main session bus. That suggested they weren’t isolated
properly, which at best causes noise on the bus and at worst could cause
spurious test failures.
Fix that by running those tests in a `GTestDBus` environment, as some of
the other appinfo tests already are.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
They get at least these `GIBaseInfo` subclasses up to a reasonable (but
not complete) coverage level.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
