Previously `gi_object_info_find_signal()` used `gi_object_info_get_signal()`
to retrieve the *i*th signal and compare its name to the desired name.
However, `gi_object_info_get_signal()` returns an allocated object.
If the names were not matching, the allocated object was simply dropped,
and this resulted in a lot of unnecessary allocations compared to the
desired number of allocations, which is one.
To avoid much of the overhead pertaining to the creation of these allocated
`GISignalInfo` objects, introduce a new function that inspects the signal
blobs directly and returns an allocated `GISignalInfo` object just for the
matching signal. The function is largely a copy-and-paste of `gi_base_info_find_vfunc()`,
which does the same thing, only for virtual functions.
See https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/504
As with the previous two commits, the results of calling
`gi_repository_get_loaded_namespaces()` were previously
non-deterministic due to being generated by iterating over a hash table,
which has a non-deterministic iteration order.
Fix that by using the new `ordered_typelibs` and `ordered_lazy_typelibs`
arrays to provide deterministic ordering.
At the same time, significantly reduce the number of allocations needed
to build the return value — previously the results would be built as a
linked list before being turned into an array. The linked list is now
banished to history.
Add some more unit tests to maximise test coverage of this method.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3303
As with the previous commit, finding a `GIBaseInfo` matching the given
error domain was non-deterministic because it iterated through a hash
table of typelibs. Hash table iteration is non-deterministic.
Change the method to instead use the `ordered_typelibs` and
`ordered_lazy_typelibs` arrays to give deterministic iteration order.
Add a unit test, although it can’t test the interesting case of an error
domain which is present in both `GioUnix`/`GioWin32` and `Gio`, because
no such error domain exists.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
When faced with a `GType` which is present in multiple typelibs, the old
implementation was not deterministic, as it iterated over a hash table
of typelibs. The iteration order of a hash table is not deterministic.
Use the new `ordered_typelibs` and `ordered_lazy_typelibs` arrays to
iterate instead, making the order deterministic.
Add a unit test to check this. In particular, to check that symbols
which are present in both `Gio` and `GioUnix` are correctly resolved as
being from `GioUnix`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
Instead, add a method on `GIRegisteredTypeInfo` which indicates whether
the registered type is a boxed type. This will return true for
`GIStructInfo` and `GIUnionInfo` instances which are boxed (not all
structs and unions are).
This makes `GIBoxedInfo` redundant, and it’ll be dropped in a following
commit.
---
There are several different things which typelibs need to be able to
represent:
1. Plain old datatype (POD) structs
2. POD unions
3. Structs with a copy func and/or free func
4. Unions with a copy func and/or free func
5. Structs which are the ‘GType struct’ for an object or interface (i.e.
the class or instance or interface struct)
6. Structs with a copy func and free func *and* boxed GType
7. Unions with a copy func and free func *and* boxed GType
8. Boxed GTypes which represent something other than a struct or union
So there’s a lot going on here. In commit
e28078c70cbf4a57c7dbd39626f43f9bd2674145, a lot of this was reworked,
and support was added for boxed unions and boxed ‘others’ (the last item
on the list above).
Since then, support for boxed types other than structs seems to have
atrophied a bit, and the whole lot has got a bit confusing.
It was perhaps less confusing when all the `GIBaseInfo` subclasses were
actually aliases of each other, but now they have subtype relationships,
the position of `GIBoxedInfo` in that type hierarchy has become unclear.
How is it related to `GIStructInfo`, `GIUnionInfo` and
`GIRegisteredTypeInfo`?
Since a boxed type is necessarily a `GIRegisteredTypeInfo`, and the
methods of `GIRegisteredTypeInfo` are all written to allow a `GType` to
be optional, so that `GIStructInfo` and `GIUnionInfo` can safely derive
from it and still be used to represent plain old datatypes without
`GType`s, it makes sense to add a method to `GIRegisteredTypeInfo` to
indicate that the registered type is derived from `G_TYPE_BOXED`.
Accordingly, the things above are now represented in libgirepository’s
type system as:
1. `GIStructInfo` instance, `GIRegisteredTypeInfo` methods return no
`GType` info
2. `GIUnionInfo` instance similarly
3. `GIStructInfo` instance, `GIRegisteredTypeInfo` methods return no
`GType` info, `gi_struct_info_get_{copy,free}_function_name()` return
non-`NULL` values
4. `GIUnionInfo` instance similarly
5. `GIStructInfo` instance, `GIRegisteredTypeInfo` methods return no
`GType` info, `gi_struct_info_is_gtype_struct()` returns true
6. `GIStructInfo` instance, `GIRegisteredTypeInfo` methods return valid
`GType` information, `gi_registered_type_info_is_boxed()` returns
true, `gi_struct_info_get_{copy,free}_function_name()` return
`NULL` values (because the copy/free functions are hidden inside the
boxed type registration at runtime)
7. `GIUnionInfo` instance similarly
8. Not representable, but could be represented in future by re-adding a
`GIBoxedInfo` type which derives from `GIRegisteredTypeInfo` and is
used solely for boxed ‘other’ types, *not* boxed structs or unions
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3245
Eventually, we want to move to using `GType` directly for everything,
since `GIBaseInfo` and its subclasses are all using `GTypeInstance`.
However, that requires quite a lot of changes and we’re about to hit the
API freeze.
So do the smallest set of changes possible to remove `GIInfoType` and
related functions from the public API, which gives us freedom to make
more changes later without breaking API.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This makes them consistent with the other getter methods in
`GIRepository` which return lists/arrays. It’s useful to return the
length, as that means the caller doesn’t have to work it out by
iterating over the entire array.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
So that it matches `gi_arg_info_get_type_info()`. We can’t use
`gi_arg_info_get_type()` because that collides with the `GType` getter
for the type.
Spotted by Philip Chimento.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3243
GI_IS_REGISTERED_TYPE_INFO() wasn't working because it was actually
defined to be the same as GI_IS_OBJECT_INFO().
Add some desultory type-checking assertions to the repository tests.
There are a handful of APIs in libgirepository which are used on
performance-sensitive code paths in language bindings (such as looking
at arguments when doing function calls). Historically libgirepository
has provided a stack-allocated variant for them, which avoids returning
a newly allocated `GIBaseInfo`. Since moving to glib.git and porting to
`GTypeInstance`, that stack allocated version has been broken.
This commit fixes it, by exposing obfuscated stack allocatable versions
of `GITypeInfo` and `GIArgInfo`, which are the two `GIBaseInfo`
subtypes which can be returned by the stack allocation functions.
The commit includes unit tests for them.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3217
Rather than them being set and stored globally, make them members of
`GIRepository`. This helps us move away from the concept of a global
singleton `GIRepository`.
This is slightly complicated by the fact that the library paths are
needed within the module loading code in `GITypelib`, but at that point
the `GITypelib` doesn’t have access to its parent `GIRepository` to call
`gi_repository_get_library_path()`, so we have to cache them in
`typelib->library_paths`.
It also means that it’s no longer possible to retrieve the ‘unset’ paths
from the globals, so the test for that is removed from
`repository-search-paths.c`.
This commit makes some API breaks, but that’s OK because libgirepository
has not been in a stable release yet.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
These tests come from gobject-introspection/tests/repository/. They
include whatever wasn't already covered by the existing tests.
The original files didn't have copyright information. That's been
reconstructed from commit messages of commits that added a test or a
substantial part of one.
They get at least these `GIBaseInfo` subclasses up to a reasonable (but
not complete) coverage level.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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
We used to store the search paths into a GSList but this is not
efficient for various reasons, so replace this with an array so that we
can replace return just a GStrv in the public API.
Generating gir and typelib files has inter-dependencies that may depend
on other elements.
For example, glib requires gobject and gdump generated files require
gmodule, so we've a cyclic dependency because gmodule requires gobject,
that requires glib.
To prevent this, let's just generate the introspection files at once in
a different meson file so that we don't have to deal with this.
As per this we could even revert commit fa37ab6d0 since gio is now
compiled before the gir files.
For the moment, this is enough to roughly verify that the port to
`GTypeInstance` has not massively broken things. It’s not anywhere near
sufficient to qualify as a proper test suite though.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
