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
There are various places where the set of typelibs is iterated over or
returned in an ordered way. In order to keep results deterministic and
reproducible, we need to keep this set ordered.
Keep a `GPtrArray` of the typelibs (one for fully-loaded ones and one
for lazy ones) alongside the existing hash tables. This will be used for
iteration in the next few commits.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
`GITypeInfo` isn’t defined in `libgirepository-internals`, and that was
forcing us to do some header includes which violated the layering
between `libigrepository-internals` and `libgirepository`. Fix that by
moving the helper function to the header/source where `GITypeInfo` is
defined.
This fixes commit 54f156bd63.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
When creating `GIBaseInfo` instances from binary blobs, so far the code
has used an undocumented implicit conversion from one enum type to the
other. That’s a bit nasty, as it means the two enum types need to be
kept in sync (without that need being documented).
Introduce an explicit conversion function to make things more explicit.
Currently it does nothing, but in an upcoming commit it will be used to
deprecate a blob type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #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
Since `GITypelib` is exposed in the public libgirepository API, it needs
to be a boxed type. So we either need to add a `copy` method to mirror
the existing `free` method, or switch to refcounting. The latter option
seems better, since a `GITypelib` contains internal state about open
`GModule`s and the semantics for copying that would be potentially
complex.
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
gi_repository_enumerate_versions() was missing a type check of the
instance parameter. This helps catch mistakes when porting from
girepository 1.x where the parameter was allowed to be null.
This was introduced by me in commit
1eec66c898, as the ownership transfer
semantics of `gi_typelib_new_from_mapped_file()` were not blatant.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3237
We now only support creating `GIRepository` instances as normal
GObjects, not as a global singleton. This makes the semantics of the
class a bit more standard and, in particular, makes it easier to ensure
that everything is freed when we’re done with libgirepository. This is
particularly useful for unit testing, but should also be useful when
unloading modules from bindings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
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
This means they’re implemented in the same file as the typelib search
path, so it’s easier to refactor the code.
This adds `gi_repository_get_library_path()` to expose the library path,
both publicly and to internal users in `gitypelib.c`. And unit tests.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`GBytes` provides a way of handling const memory blobs, stolen memory
blobs, and mapped files. Rather than having `GITypelib` implement all of
those itself, just take a `GBytes` as input.
This is an API break, but libgirepository hasn’t been in a stable
release yet.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Might as well move to a modern way of declaring GObjects. This means
that `GIRepository` is no longer derivable, but it would be a bit
unexpected if anyone was deriving from it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
By shifting responsibility for ensuring that the lifetime of a
`GIRepository` always exceeds the lifetime of any of its `GIBaseInfo`s
to the user.
Keeping a weak ref from each `GIBaseInfo` to its `GIRepository` would be
too expensive (`GIBaseInfo`s are supposed to be cheap to create and
destroy, as they are used within function calls in language bindings).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3234
We are using various indexes types, but not always using the correct
sign or size, so let's adapt this to ensure we're consistent with the
values we're comparing with.
Even though we expose member access as size_t, a GI info blob can
typically just access to an a number of values that is never bigger
than uint16_t, as that's how the typelib is defined (cfr. typelib
internal header blob sizes and n_* elements).
So let's avoid this to happen by adding a check.
We just do a safe s/gsize/size_t/ replacement here without doing any
changes to places in which different size of size_t and gsize may be
actually different and create troubles.
And rename it to `gi_repository_get_shared_libraries()`. Previously it
returned a comma-separated string, which wasn’t particularly typesafe or
machine-friendly. Now it returns the same data as an array.
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Having it be nullable means the type system forces the caller to check
the result for nullability every time, even though it’s straightforward
for the caller to check the index argument in advance and guarantee a
non-`NULL` result.
Change `gi_repository_get_info()` to never return `NULL` to tidy this
up. This also brings it inline with other `gi_*_get_info()` functions,
which are not nullable.
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
A few applications such as gnome-music load the GIRepository typelib
and use it to adjust their search paths.
GLib 2.79.x now provides libgirepository-2.0.so.0 (GIRepository-3.0),
but each OS distribution is likely to have a transitional period during
which GLib's libgirepository-2.0.so.0 has become available, but bindings
like PyGI and gjs are still linked to gobject-introspection's
libgirepository-1.0.so.1 (GIRepository-2.0).
During this transitional period, interpreted languages that load the
GIRepository namespace could get the "wrong" version, which will result
in adjusting a search path that will not actually affect the language
binding's typelib lookup, and could also lead to symbol and type-system
conflicts.
We can avoid this collision by making GLib's GIRepository library refuse
to load versions of the GIRepository typelib that are not 3.0, and
similarly making gobject-introspection's GIRepository library refuse to
load typelib versions that are not 2.0. A relatively neat way to achieve
that is to make each version behave as if the other one doesn't exist.
Signed-off-by: Simon McVittie <smcv@debian.org>
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.
Review and update the documentation, making sure it’s complete,
formatted in gi-docgen format, and has all appropriate GIR annotations
and `Since:` lines.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Accepting two filenames as a string comma-separated string seems like a
layering violation: this is a public API which could be used in places
other than directly off a set of command line arguments.
Move the command line argument parsing to the command line callback.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
It’s not intended that most people will use this, but it’s going to be
quite useful for adding unit tests — we don’t really want the unit tests
to share global state (a singleton `GIRepository`) between tests.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This method doesn’t return a `GType`, so when the code gets ported to
`GTypeInstance` in an upcoming commit, that will become quite confusing.
Rename it to `gi_base_info_get_info_type()` instead.
This introduces no functional changes, but it is an API break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
These aren’t needed at the moment, since all the `TypeInfo` structs in
libgirepository are all aliases for each other.
An upcoming commit will change that, however, so we need to be a little
bit stricter about type safety in advance.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Now that libgirepository uses `GI_AVAILABLE_IN_*` macros, that’s what
controls symbol visibility. The `_` prefixes are redundant, and out of
keeping with the rest of GLib.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Rather than a mix of structs being in `GI` and their methods being in
`g_`.
We’ve chosen not to use the `g_` namespace because a number of the
libgirepository class names are quite generic, so we’d end up with
confusing symbols like `GScopeType` and `GArgument`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
