summaryrefslogtreecommitdiff
path: root/girepository
Commit message (Collapse)AuthorAgeFilesLines
* gi[callable|type]info.c: Avoid MSVC C4098 warningsChun-wei Fan2022-03-282-4/+4
| | | | | | | | | We attempted to return a value in void-return-type functions in both gicallableinfo.c and gitypeinfo.c, so avoid that since that will trigger a C4098 warning on Visual Studio, which is considered an error if we are building against an installed version of GLib 2.68.x or later. This will fix builds against GLib-2.68.x and later on Visual Studio.
* gitypeinfo: Add pointer-stuffing functions for GITypeTag storage typePhilip Chimento2022-02-162-20/+84
| | | | | | | | | | | | | | | | | | | | | This adds gi_type_tag_argument_from_hash_pointer() and gi_type_tag_hash_pointer_from_argument(). They do the same thing as the corresponding g_type_info_... functions, which are used to pack and unpack the correct field of a GIArgument into/from a data pointer in GHashTable or GList, regardless of machine architecture or endianness. These functions take a GITypeTag obtained from g_type_info_get_storage_type(), instead of a GITypeInfo pointer. (The storage type is the only piece of data that is actually 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. The original g_type_info_... functions are reimplemented in terms of the new g_type_tag... functions.
* bdz.c: Some cleanupsChun-wei Fan2022-02-131-9/+1
| | | | | | | | We can just update the for loop condition to be >0 for all builds, which is actually equivilant to >=1 as we are essentially comparing an unsigned 32-bit int, so that we don't need to worry about fixing the VS2012 bug invasively, as Visual Studio 2012 x64 is more sensitive about sizes of variables (e.g. pointer sizes in this case)
* brz.c: Consider _WIN64 for 64-bit pointers tooChun-wei Fan2022-02-131-8/+12
| | | | | | | | | | | The __ia64 and __x86_64__ macros are defined for GCC but not Visual Studio, but actually this code path should also be taken for Visual Studio when doing a 64-bit build (x86_64/x64 and aarch64/arm64, _WIN64 will be defined for these cases), since Windows is an LLP64 platform. This will avoid C4311/C4312 warnings on Visual Studio builds, which are often warnings of concern as we are dealing with pointers with differing sizes on 32-bit and 64-bit Windows builds.
* brz.c: Avoid C4715 warningsChun-wei Fan2022-02-131-1/+3
| | | | | | | | | Later GLib versions assume that warning C4715 is an error as we want ot be sure that functions that return a value do indeed return one by all means. Avoid this warning by adding a 'return 0' in brz_search_packed(), it might be pointless but does indeed avoid the warning.
* Rename argument in the declationEmmanuele Bassi2022-02-131-1/+1
| | | | It must match the argument in the definition and the documentation.
* Use GI_TYPE_TAG_IS_BASICEmmanuele Bassi2022-02-134-6/+6
| | | | Now that we have it.
* Add GI_TYPE_TAG_IS_BASICEmmanuele Bassi2022-02-131-1/+33
| | | | | And deprecate G_TYPE_TAG_IS_BASIC. Let's avoid hijacking the G namespace any further.
* docs: Rename a field annotationEmmanuele Bassi2022-02-131-1/+1
|
* docs: Reformat a long descriptionEmmanuele Bassi2022-02-131-0/+4
|
* docs: Remove DocBook tagsEmmanuele Bassi2022-02-1318-246/+117
| | | | | We are still using gtk-doc, but gtk-doc uses Markdown these days, not DocBook.
* Use the proper private triglyphEmmanuele Bassi2022-02-134-5/+4
| | | | It's `/*< ... >*/`, not `/* <...> */`.
* girffi: Add gi_type_tag_extract_ffi_return_value()Philip Chimento2022-02-132-26/+62
| | | | | | | | | | | | | | | | 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().
* girepository: Fix documentation commentsPhilip Chimento2022-02-131-4/+4
| | | | | It was driving me crazy that g_type_info_get_array_length() claimed to return an array length.
* girepository: Clarify SimpleTypeBlob documentationPhilip Chimento2022-02-131-3/+3
| | | | | | | 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.
* gitypeinfo: Add GI_TYPE_TAG_IS_CONTAINER macroPhilip Chimento2022-02-132-4/+16
| | | | | Like GI_TYPE_TAG_IS_NUMERIC, this is a convenience for bindings that want to perform a similar action for all container types.
* gitypeinfo: Add GI_TYPE_TAG_IS_NUMERIC macroPhilip Chimento2022-02-132-2/+12
| | | | | | | | | | | | | | | | | | | | | 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.
* girepository: avoids segfault in case of bad gtypeLukas Oberhuber2022-01-121-1/+3
| | | | | | | 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.
* cmph: Handle fgets() return valueEmmanuele Bassi2022-01-111-1/+1
| | | | | Newer versions of the GNU libc have started to warn if the result of the call is unused.
* Add "forever" scopeEmmanuele Bassi2022-01-093-6/+14
| | | | | | | | 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
* gitypelib.c: on macOS, treat @-prefixed shlib paths as absoluteRok Mandeljc2021-11-271-0/+10
| | | | | | | | 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).
* Do not use GLib versioning symbolsEmmanuele Bassi2021-11-241-30/+40
| | | | | | | | | 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.
* Remove runtime warnings, add doxygen deprecation noticesCimbali2021-11-231-8/+8
|
* Fix styling issues from suggestionsEmmanuele Bassi2021-11-231-5/+7
|
* Avoid leaking memory from FFI closure if no segfault riskCimbali2021-11-231-0/+3
|
* Create new API for libffi closuresCimbali2021-11-233-16/+94
| | | | Deprecate the previous API as per discussion in !283.
* girffi.h: add g_callable_info_get_closure_native_address() APISergei Trofimovich2021-11-232-0/+22
| | | | | | | | | | | | | 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>
* girffi.c: fix return value for g_callable_info_prepare_closure()Sergei Trofimovich2021-11-231-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: https://github.com/libffi/libffi/commit/9ba559217bea0803263a9a9a0bafcf9203606f5b Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
* Improve readability of error messageEmmanuele Bassi2021-08-051-3/+3
| | | | | Use the parent type and the function symbol when erroring out if we can't find a property accessor.
* Use a macro for the missing accessor sentinel valueEmmanuele Bassi2021-08-053-8/+10
| | | | Easier to read than `0x3ff`.
* Add introspection data for property accessorsEmmanuele Bassi2021-08-057-1/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add new annotations for property accessorsEmmanuele Bassi2021-08-054-6/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Property accessors work for interfaces and objectsEmmanuele Bassi2021-08-051-4/+16
| | | | | | We need to check the container type before trying to obtain a GIPropertyInfo for GIFunctionInfos that have a SETTER or a GETTER flag set.
* Add "final" class attributeEmmanuele Bassi2021-08-058-3/+54
| | | | | | | | 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.
* Add version macros for 1.70Emmanuele Bassi2021-08-051-0/+6
| | | | We are going to introduce new API.
* Initialise argumentEmmanuele Bassi2021-06-241-1/+1
| | | | Avoid a "maybe uninitialized" compiler warning.
* girepository: Fix leak in prefix_with_contextDavid King2021-06-181-1/+3
| | | | | | Found by Coverity. https://bugzilla.redhat.com/show_bug.cgi?id=1938731
* girepository: Fix leak in write_vfunc_infoDavid King2021-06-181-1/+4
| | | | | | Found by Coverity. https://bugzilla.redhat.com/show_bug.cgi?id=1938731
* girepository: Fix leak in write_field_infoDavid King2021-06-181-0/+1
| | | | | | Unref type before reusing it. Found by Coverity. https://bugzilla.redhat.com/show_bug.cgi?id=1938731
* girepository: Fix leak in _g_ir_parser_parse_fileDavid King2021-06-181-1/+5
| | | | | | Found by Coverity. https://bugzilla.redhat.com/show_bug.cgi?id=1938731
* girepository: Fix leak in g_callable_info_invokeDavid King2021-06-181-1/+4
| | | | | | Found by Coverity. https://bugzilla.redhat.com/show_bug.cgi?id=1938731
* Make test suite work with cross-related optionsJohn Ericson2021-05-231-7/+0
| | | | | | | | | | 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`
* Use g_memdup2() with newer versions of GLibEmmanuele Bassi2021-03-121-1/+9
| | | | | The g_memdup() function has been deprecated, so we should use the new g_memdup2() function if available.
* Merge branch 'objectinfo_nullable' into 'master'Mathieu Duponchelle2020-07-221-14/+14
|\ | | | | | | | | Add missing nullable annotations to GObjectInfo See merge request GNOME/gobject-introspection!225
| * Add missing nullable annotations to GObjectInfoJonne Haß2020-05-261-14/+14
| |
* | Merge branch 'standalone-doc-sections' into 'master'Mathieu Duponchelle2020-07-221-1/+2
|\ \ | | | | | | | | | | | | Add the notion of standalone doc sections. See merge request GNOME/gobject-introspection!226
| * | Add the notion of standalone doc sections.Mathieu Duponchelle2020-07-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | meson: also build gi-dump-types on WindowsChristoph Reiter2020-05-192-2/+3
| | |
* | | Use `_get_oshandle()` and `g_win32_output_stream_new()` instead sinceGisle Vanem2020-05-151-1/+5
| | | | | | | | | | | | | | | | | | `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?
* | | Obs! Change back to `g_unix_output_stream_new()` for non-Win32.Gisle Vanem2020-05-141-1/+1
| | |