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
`GIIrNodeUnion` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`GIIrNodeEnum` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`GIIrNodeField` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
This also includes some offset validity changes which were forgotten
from commit 515b3fc1dc.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`GIIrNodeVFunc` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`class_closure` isn’t actually meaningfully set anywhere in the code yet
(there are FIXME comments), so I’m not sure of the best type for it. But
generally `unsigned` is more widely used than signed `int`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`GIIrNodeType` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`g_strdup(NULL)` is guaranteed to return `NULL`, so there’s no need to
branch to handle that.
Add a stub private doc comment to hold a `(nullable)` annotation for
that argument, though, so that information isn’t lost.
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
This is just for future reference for people reading the code in future.
I was going through and checking to see if any of them needed to be made
`const` (none of them did).
I did find a couple of memory leaks though; see the following commits.
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
These flags were replaced by gi_callable_info_can_throw_error() in
girepository 1.x, but the flags were maintained for backwards
compatibility. No need to hold on to them in the 2.x API.
Note that these flags are also still maintained as separate bits in the
binary format, which is not changing. So, they still need to be read
from FunctionBlob and VFuncBlob if the bit is not set in SignatureBlob.
This is an API break for girepository 2.x, which is OK because the API
has never been released yet.
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.
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 removes the gthash utility functions from the ABI, so link those
into their automated test statically.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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
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
