This new API does the same thing as gi_type_info_extract_ffi_return_value,
but takes a GITypeTag instead of GITypeInfo pointer, and additionally a
GIInfoType if the GITypeTag is GI_TYPE_TAG_INTERFACE. (These pieces of
data are the only things used from the GITypeInfo structure.)
It's intended for bindings using an argument cache, such as GJS and
PyGObject, so that they don't have to store a whole 64-bit GITypeInfo
pointer in their cache in many common cases, and can just store the 5-bit
type tag instead, or the 5-bit interface type in case of
GI_TYPE_TAG_INTERFACE.
The original gi_type_info_extract_ffi_return_value() is reimplemented in
terms of the new gi_type_tag_extract_ffi_return_value().
The documentation comment for SimpleTypeBlob seemed to imply that a basic
type was embedded if the reserved fields were nonzero. After examining the
code, I believe that was actually due to some words missing, and the
comment should say that the type is embedded if the fields are zero.
This is a convenience for bindings that want to perform a similar action
for all numeric types. It allows more expressive code in some cases:
if (GI_TYPE_TAG_IS_NUMERIC(tag)) {
do_one_thing();
return;
}
switch (tag) {
case GI_TYPE_TAG_ARRAY:
do_other_thing();
return;
/* ... */
default:
g_assert_not_reached();
}
instead of listing out all of the numeric types in the switch statement.
If a <GType invalid> (that's the way it appears in python's debugger) is
returned, `g_type_name` returns NULL. This
function therefore returns NULL at this time
as subsequent calls to `strlen( data->gtype_name)` segfault.
Some functions are meant to exist for the entire duration of the
process, and thus have no need for a notification function because
one will never be called.
Fixes: #49
On macOS, @-prefixed shlib paths (@rpath, @executable_path, and
@loader_path) need to be treated as absolute. Trying to combine them
with a configured library path produces a mangled path that is
unresolvable and may cause unintended side effects (such as loading
the library from a fall-back location on macOS 12.0.1).
Libgirepository is not GLib, and it should not use GLIB_DEPRECATED,
GLIB_DEPRECATED_FOR, and GLIB_UNAVAILABLE macros (as the GLib
documentation clearly states).
When using them, we don't get the proper macro expansion, so deprecated
symbols suddenly disappear from our shared library.
Commit 6bab939bf ("girffi.c: fix return value for g_callable_info_prepare_closure()")
effectively changes semantics of return value from code pointer to data pinter (closure).
`gjs` (and probably other software) relies on old (incorrect) semantics of
g_callable_info_prepare_closure(): https://gitlab.gnome.org/GNOME/gjs/-/issues/428
This change exposes the API that allows extracting directly
callacble code pointer. `gjs` will have to adapt to the new API.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
The initial failure was observed on `meld` against recently released
`libffi-3.4-rc1`. There `meld` crashes as:
```
$ meld
Segmentation fault (core dumped)
$ gdb --args /usr/bin/python3.9 /usr/bin/meld
(gdb) run
...
Thread 1 "python3.9" received signal SIGSEGV, Segmentation fault.
0x00007fffe9ac1ae8 in g_callable_info_free_closure (
callable_info=0x555555d45990, closure=0x7fffe9e70c20)
at ../gobject-introspection-1.68.0/girepository/girffi.c:428
428 g_free (wrapper->ffi_closure.cif->arg_types);
(gdb) bt
callable_info=0x555555d45990, closure=0x7fffe9e70c20)
at ../gobject-introspection-1.68.0/girepository/girffi.c:428
data=0x555555d252d0)
at ../pygobject-3.40.1/gi/pygi-closure.c:635
...
```
The bug here is in type mismatch between expected return value of
`g_callable_info_prepare_closure()` and actual value (executable
code pointer):
```c
ffi_closure * g_callable_info_prepare_closure(...) {
gpointer exec_ptr;
...
status = ffi_prep_closure_loc (&closure->ffi_closure, cif, callback, user_data, exec_ptr);
return exec_ptr;
}
```
Note: `exec_ptr` is a code pointer that could be directly executed by
caller, like `((rt (*)(a1,a2))exec_ptr)(1,2);` It should never be wrapped
into an `ffi_closure*`, which is normally called via `ffi_call(closure, ...)`.
We see the problem when we try to free direct code pointer instead of
`ffi_closure()` as starting from libffi-3.4 executable trampoline and
`ffi_closure()` don't necessarily live in the same block:
9ba559217b
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
A GObject property can be accessed generically through the GObject API,
e.g. g_object_set_property() and g_object_get_property(). Properties
typically also have public accessor functions, which are (according to
our own best practices) called through the generic API.
The introspection data is currently missing the relation between a
property and its public accessor functions. With this information, a
language binding could, for instance, avoid exposing the C API entirely,
thus minimizing the chances of collisions between property names and
accessor functions; alternatively, a binding could call the C API
directly instead of going through the generic GObject API, thus avoiding
the boxing and unboxing from a native type to a GIArgument and finally
into a GValue, and vice versa.
In the GIR, we add two new attributes to the `property` element:
- setter="SYMBOL"
- getter="SYMBOL"
where "symbol" is the C function identifier of the setter and getter
functions, respectively. The `setter` attribute is only applied to
writable, non-construct-only properties; the `getter` attribute is only
applied to readable properties.
We maintain the ABI compatibility of the typelib data by using 20 bits
of the 25 reserved bits inside the PropertyBlob structure. The data is
exposed through two new GIPropertyInfo methods:
- g_property_info_get_setter()
- g_property_info_get_getter()
which return the GIFunctionInfo for the setter and getter functions,
respectively.
We introduce two new annotations:
- (set-property PROPERTY_NAME)
- (get-property PROPERTY_NAME)
These annotations are valid inside function blocks for methods on
objects and interfaces, and define whether a function is a property
accessor, e.g.:
/**
* gtk_widget_set_name: (set-property name)
* @self: ...
* @name: ...
*
* ...
*/
/**
* gtk_widget_get_name: (get-property name)
* @self: ...
*
* ...
*
* Returns: ...
*/
The annotations are transformed into the GIR data as attributes:
- glib:set-property="PROPERTY_NAME"
- glib:get-property="PROPERTY_NAME"
The underlying typelib data has had flags for setter and getter
functions for a while, but they have never been plugged into the GIR
data or the introspection scanner. Now they are; you can retrieve the
GIPropertyInfo from a GIFunctionInfo that has the GI_FUNCTION_IS_SETTER
or GI_FUNCTION_IS_GETTER flags set.
Fixes: #13
A "final" class is a leaf node in a derivable type hierarchy, and cannot
be derived any further.
This matches the changes in libgobject that introduced G_TYPE_FLAG_FINAL
to the type flags.
Because of skepticism I received in #224, I made this PR which keeps the
testsuite and CI improvements but doesn't add any new build options. I
hope this would be less controversial:
- no new knobs
- tests for those using existing build options
- CI tests `build_introspection_data = false`
Up to now, section annotations had to match a class or interface
name in order to be serialized in the gir.
With this commit, they now get serialized as docsection nodes,
for potential use by documentation tools.
`g_win32_output_stream_new_from_fd()` is private in Gio.
It's normally not exported unless `GLIB_STATIC_COMPILATION` is effective.
PS. Why would i not be called `GIO_STATIC_COMPILATION` for Gio .c-files?
This functionality is used in both PyGObject and GJS, and if not done
correctly can lead to architecture-specific bugs. It seems best to add
API in gobject-introspection for the correct way to do it.
See also: GNOME/gjs#309
ba744068 ("Make meson.override_find_program working on more complex use
cases") made the build no longer reproducible by encoding a build system
path into the output. This shouldn't be necessary anyway, since it
should be possible to add new paths to search for gir files by setting
the XDG_DATA_DIR environment variable.
Closes#318
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
There are notably 4 classes of GTypes where a girepository lookup
might fail:
- GTypes from private interfaces in public objects (eg. MetaCullable in
mutter)
- GTypes for private base objects with public interfaces (eg. GLocalFile
in GLib)
- GTypes registered from the language, and presumably not coming from the
GIR
- GTypes of objects/interfaces that we didn't load a typelib for
It is moot to look for those over and over again, and a full lookup can
be taxing if looking up for a method/property on objects with those
characteristics.
It seems we can cache the misses too, so next lookups are just as quick
as an introspected GType. The cache is invalidated after loading new
typelibs, in case some of the previously missed GTypes is now properly
introspected.
