Foreign structs are special in the sense that there might
be native bindings (for instance PyCairo for PyGI) that provides
the same functionallity as the introspected variant.
https://bugzilla.gnome.org/show_bug.cgi?id=610357
To make things really better we should track the line origin of
element from the .gir file (and actually we need to do better
checking in the scanner), but this is slightly less lame.
When looking at an embedded type (e.g. a Callback after a Field), the
offset we put in the info structure was to the CallbackBlob itself.
However the code in g_type_info_get_interface assumed that the offset
was to a SimpleTypeBlob, which it wasn't.
https://bugzilla.gnome.org/show_bug.cgi?id=606180
We don't want to malloc each GIBaseInfo when they can be used in
function invocation; instead, allow stack allocation.
There were a lot of structure typedefs which were actually just
exactly the same as GIBaseInfo, with the one exception of GITypeInfo.
Instead, just put the single GITypeInfo boolean inside GIBaseInfo
as a bit in a bitfield.
GIBaseInfo is still opaque publicly; GIRealInfo is the new
internal structure.
Using this, add new functions to retrieve arguments and argument types
on the stack.
https://bugzilla.gnome.org/show_bug.cgi?id=604074
Rather than having bindings use g_function_info_invoke, which is basically
a toy/demo API, export a convenience utility function which takes the introspection
information and sets up things we need to pass to libffi.
Then invocation can be done directly to libffi by a binding.
As part of this work, remove some (unused by gjs) public functions from the
girffi API, and instead export a function to map to libffi which can work
semi-correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=604074
Due to a missing header, gobject-introspection fails to compile on OpenBSD.
And only due to headers-including-headers practice this doesn't blow up on
many other platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=596226
In the case where a known class derives from a hidden one, we want
to use the most-derived parent class, rather than simply falling back
to GObject.
Example:
ShellEmbedWidget in gnome-shell derives from ClutterGLXTexturePixmap from clutter,
which is a hidden class. ClutterGLXTexturePixmap's parent itself is
ClutterX11TexturePixmap, which is also hidden. But its parent is
ClutterTexture, which we do know. Use that.
https://bugzilla.gnome.org/show_bug.cgi?id=598993
We are treating GIUnresolvedInfo as a GIBaseInfo, but the structures
had drifted out of sync. Add a repository pointer and bring them
back into sync.
Based on a report and patch from Jan Hudec <bulb@ucw.cz>
It's was busted that g_typelib_new_* does the dlopen() since that caused
g-ir-compiler to load the modules even though it wasn't going to do
anything with them.
Instead, change things so that g_module_symbol does the dlopen on-demand.
Remove the extra dlopen(NULL) inside girepository.c, we had another
already in gtypelib.c.
Thanks to Owen Taylor for suggesting this approach.
Add type tags for short and ushort, plus all of the requisite code needed
to utilize them in libgirepository.
Add support in the scanner's AST files.
Add test functions to the everything library and the expected gir file.
gtypelib.c constant validation fixed by Colin Walters <walters@verbum.org>
When ./configure --prefix $HOME/some/where is used gobject-introspection
will happily install the files into $HOME/some/where/data/gir-1.0 but
it will refuse to find them. Apply the same trick as in
girepository/girepository.c:init_globals to find the gir files.
Unifiy the name gir-1.0 in GIR_SUFFIX and use it throughout the
project, introduce GIR_DIR which holds the path to the gir files and
update girparser and transformer.py to look into this path.
The enumeration values cited here were out of date. Rewrite to eliminate
the explicit mention of the enumeration value, to prevent it from
drifting out of date again in the future.
Parse the c:prefix from the .gir, include it in the header. Armed with this
information, we can now optimize lookups of GTypes because we
have the requirement that GTypes must start with the c:prefix. We do
fall back though if a lookup fails.
Broadly speaking, this change adds the concept of <vfunc> to the .gir.
The typelib already had most of the infrastructure for virtual functions,
though there is one API addition.
The scanner assumes that any class callback slot that doesn't match
a signal name is a virtual. In the .gir, we write out *both* the <method>
wrapper and a <vfunc>. If we can determine an association between
them (based on the names matching, or a new Virtual: annotation),
then we notate that in the .gir.
The typelib gains an association from the vfunc to the function, if
it exists. This will be useful for bindings since they already know
how to consume FunctionInfo.
We now support an extensible mechanism where arbitrary key-value
pairs may be associated with almost all items, including objects,
methods, and properties.
These attributes appear in both the .gir and the .typelib.
Similar to GObject class structs, we pair up GInterfaces with
their C structures.
Also, move some GLib-specific things into glibast.py, and make
the naming more generic.
