It’s unclear why there was a hole in this. Let’s keep things less
confusing by eliminating it.
Fixes commit 453dd4be9e.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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 effectively reverts commit 0910e2f6ad. I thought that `GIInfoType`
was decoupled from `GITypelibBlobType`, but it turns out that
`girepository.c` calls `gi_info_new_full()` with blob types, implicitly
converting them to info types.
This was causing anything with a type higher than the `INVALID_0` value
to be loaded as the wrong type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
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
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.
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
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.
It was deprecated since before libgirepository was moved into this
repository. Take the opportunity now to remove it entirely, as it’s a
bit confusing to have it in the public API.
This should not affect the binary typelib format, as it still has its
`BLOB_TYPE_INVALID_0` member, and that will remain in place until the
binary format next breaks compatibility (no plans to do that).
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
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
This adds more type safety to libgirepository, and allows
differentiating the `GIBaseInfo` derived types using the type system.
Two new derived types had to be added (previously they were just a
collection of helper methods which worked directly on a `GIBaseInfo` and
didn’t check types): `GICallbackInfo` and `GIUnresolvedInfo`.
Further cleanups and refactoring might be needed on this, but the core
of libgirepository now uses `GTypeInstance` and appears to still work
(it’s difficult to be entirely sure because there are no unit tests
yet).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Move the SECTION into the struct docs, update the documentation comment
syntax, and add `Since: 2.80` everywhere.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Move the SECTION into the struct docs, update the documentation comment
syntax, and add `Since: 2.80` everywhere.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Otherwise the GIR generation for libgirepository doesn’t work, as GLib
doesn’t get pulled in to provide basic types.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
After bumping the major version number, we don’t need backwards
compatibility any more.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Add the SPDX license runes to all the files which have an obvious
copyright header already. This is a mechanical edit.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3155
The introspection API has lived out of tree far too long. It has the
same ABI guarantees as the rest of GLib, so it has no reason to be split
from the main library.
The gobject-introspection project can depend on libgirepository, and the
language bindings can drop the gobject-introspection-1.0 dependency.
