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.
The "--code" option was removed years ago in d5b8d8d523c3bc26aa9fe6c364d3a17d325b55b6
so remove references to it from README and g-ir-compiler(1)
Remove the "--no-init" option from g-ir-compiler and g-ir-compiler(1)
as it was documented to "can only be used if --code is also specified",
so no reason to keep it around.
Return a non-zero result when opening the output file fails and
don't use g_error() for other failures when writing out the file,
since such errors should not produce a core dump.
We never actually include multiple modules in the compiler,
so just nuke that. Also rather than passing around GIrModule
consistently pass around a GIrTypelibBuild structure which
has various things.
This lets us maintain a stack there which we can walk for
better error messages.
Also, fix up the node lookup in giroffsets.c; previously
it didn't really handle includes correctly. We really need to
switch to always using Foo.Bar (i.e. GIName) names internally...
