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
Note that for alignments we should actually use size_t, but this would
imply some refactors since this value can be acually set to -1 in our
implementation.
So we use gssize for now, that at least on gcc is defined.
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.
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.
