The previous commit enabled the `/run/mount/utab` monitoring. The problem
is that the `mount-changed` signal can be emitted twice for one mount. One
for the `/proc/mounts` file change and another one for the `/run/media/utab`
file change. This is still not ideal because e.g. the `GMount` objects for
mounts with the `x-gvfs-hide` option are added and immediately removed.
Let's enable the `mnt_monitor_veil_kernel` option to avoid this.
Related: https://github.com/util-linux/util-linux/pull/2725
The `GUnixMountMonitor` object implements monitoring on its own currently.
Only the `/proc/mounts` file changes are monitored. It is not aware of the
`/run/mount/utab` file changes. This file contains the userspace mount
options (e.g. `x-gvfs-notrash`, `x-gvfs-hide`) among others. There is a
problem when `/sbin/mount.<type>` (e.g. `mount.nfs`) helper programs are
used. In that case, the `/run/mount/utab` file is updated later than the
`/proc/mounts` file and thus the `GUnixMountMonitor` clients (e.g.
`gvfs-udisks2-volume-monitor`, `gvfsd-trash`) don't see the userspace
options until the next `mount-changed` signal. Let's use the `libmnt_monitor`
API for monitoring instead and emit the `mount-changed` signal also when the
`/run/mount/utab` file is changed.
Related: https://issues.redhat.com/browse/RHEL-14607
Related: https://github.com/util-linux/util-linux/pull/2607
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>
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>
These follow GObject conventions, using `G_TYPE_CHECK_INSTANCE_CAST` to
cast to the given type, and potentially performing some runtime checks
of the type instance’s `GType` too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3216
Just like is done with `g_object_{ref,unref}()`, make these functions
take a `void*` rather than a `GIBaseInfo*`, since they’ll most likely be
called with a type which is derived from `GIBaseInfo*` rather than a
`GIBaseInfo*` itself.
Add some runtime type checks to make up for lowering the compile time
type safety.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
This means they’re now using the `GType` type system rather than the old
`GIInfoType` type system. Given the preceding few commits, these two
systems should now be equivalent.
This makes the type handling more conventional and hence a bit simpler
for people to use if they have experience with GObject.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
There are various info types which were previously treated as subtypes
of `GIRegisteredTypeInfo` by the runtime type system in the old version
of libgirepository.
Change the new type tree to reflect that, making several types now be
subtypes of `GIRegisteredTypeInfo`, and making `GIRegisteredTypeInfo`
abstract.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
Boxed types are already represented within `GIInfoType`, so they should
have a `GType` representation as well.
In an upcoming commit, this will allow us to represent the subtype
relation between `GIBoxedInfo` and `GIRegisteredTypeInfo` too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
Flag enums are already treated as a special kind of enum within
`GIInfoType`, so it would be tidier to give it its own `GType` too, with
a subtype relation to `GI_TYPE_ENUM_INFO`.
This will simplify implementing `GI_IS_ENUM_INFO` in a following commit
too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
Previously (and incorrectly), `GICallableInfo`, `GIFunctionInfo`,
`GICallbackInfo`, `GISignalInfo` and `GIVFuncInfo` were all derived
directly from `GIBaseInfo`. `GICallableInfo` is supposed to represent
all of the other types, though, so that type hierarchy was incorrect. It
dated from when all the types were aliases of each other and the type
management was done entirely at runtime.
Fix that by making the other four types derive from `GICallableInfo`,
and marking `GICallableInfo` as abstract.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
This doesn’t change the type hierarchy for now (i.e. it introduces no
functional changes), but it will allow us to add some intermediate types
into the `GIBaseInfo` hierarchy in an upcoming commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
This doesn’t change any of the flags for now (i.e. it introduces no
functional changes), but it will allow us to make some of the types
abstract in an upcoming commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
This makes `GIBaseInfo` and derived types more consistent with GObject
convention, and thus a bit more comfortable to use.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3216
It’s a separate type, so it would be less confusing if it were in its
own file.
This doesn’t change any API.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Do this by tracking the state of the size/alignment calculations
separately, rather than bunging it into the `alignment` field using
magic values.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
It’s not useful for lcov to demand branch coverage of all branches
within `g_clear_*()` functions (such as `g_clear_pointer()`). By
choosing to use `g_clear_*()`, the programmer explicitly doesn’t care
about whether the pointer is `NULL`. The tests shouldn’t have to either.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It is common to declare a mutex locker variable and to not use it in the
scope. That causes clang to warn about unused variable which is not
entirely true since the cleanup function IS the intended usage.
Work around that issue with a new macro that uses G_GNUC_UNUSED and
has the extra advantage of being less verbose.
Fixes: #3223.
As with previous commits, don’t use up half the return value space to
indicate an invalid index.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Rather than mixing `-1` and valid indexes, split out the indication of
whether the type is an array with a length argument from the actual
index of the length argument.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`-1` isn’t part of `GIArrayType`, so it’s not particularly type safe to
return it from `gi_type_info_get_array_type()`. Instead, make it an
error to call that function on a type which isn’t an array type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Return information about whether the type is a fixed-size array
separately from the array size, which allows us to use the full `size_t`
for the array size.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Note that for alignments we should actually use size_t, but this would
imply some refactors since this value can be acually set to -1 in our
implementation.
So we use gssize for now, that at least on gcc is defined.
