It’s actually a factory method rather than a constructor, since
`GIBaseInfo` is abstract, but despite that, changing the name so it sits
inside the `GIBaseInfo` class makes sense. There is no `GIInfo` type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Fix the declaration and documentation of
`gi_object_info_find_method_using_interfaces()` and
`gi_object_info_find_vfunc_using_interfaces()`. The documentation was
wrong when I wrote it: the value returned is the object or interface
which declares the method or vfunc, not the one which implements it.
The returned declarer info may be a `GIObjectInfo` or a
`GIInterfaceInfo`. Since those two types have no subtype relation
between them, the return type has to be changed to `GIBaseInfo`. Using
`GIObjectInfo` would have been fine in girepository-1.0 because all
`*Info` types were aliases of each other — but since the move to
`GTypeInstance` this is no longer true.
A unit test will be in the following commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3246
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 used to use unsigned values, while they should be big enough to old
the data we're handling here, it's cleaner and clearer if we use size_t
as type for such values, as it makes straight forward to understand what
a value should contain. It also makes these values more future proof.
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
Because they return the function name, not a `GIFunctionInfo` for the
function, or anything else.
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
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
Make sure that each C file in `girepository/` includes its corresponding
header file (if such a file exists).
This ensures that the first declaration the compiler sees for each
function contains the symbol visibility macros. This fixes symbol export
(`dllexport`) on Windows platforms.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3155
The pkg-config file sets the include directory to the level above
`girepository/`, just like with GIO, GObject and GModule.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
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
