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
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.
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.
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.
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.
Not sure what it was doing there — these arguments get written to as
part of the invocation. The in-args should be `const` qualified, but not
the out-args.
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
The whole point of a `GICallableInfo` struct is to contain information
about how a function is callable, and that includes information about
whether it’s a method and whether it throws a `GError`. The caller
shouldn’t need to specify those things separately.
So drop those arguments.
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
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
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
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
