Rather than having a regex for both builds, but *also* use a symbol
file for the MSVC build which would bitrot quickly, force us to update
the .symbols file by using it for Unix too.
Add some missing symbols.
This is the listing of symbols to export from the main libgirepository
.dll/.so. This is used for example to generate the .lib file from the
Windows DLL.
https://bugzilla.gnome.org/show_bug.cgi?id=681820
-Make code using libgirepository_internals relocatable on Windows,
like what is done in the GTK+ stack, and the girepository DLL.
-Remove C99isms
-"interface" is a reserved keyword on certain compilers, so change that to
"giinterface"
https://bugzilla.gnome.org/show_bug.cgi?id=681820
...So that it will compile on non-C99 compilers. The changes are mainly
moving the variable declarations to the start of the resecptive blocks.
Also, replace the use of buflen in chd.c as it might not be defined for all
platforms, instead using packed_cr_size as it seems to represent the value
that is to be printed/displayed by the debugging output.
https://bugzilla.gnome.org/show_bug.cgi?id=681820
Namely, those that are methods and those that throw GErrors.
We have very similar code in two places that calculate arg lengths and
argument types to stick into libffi. Merge, clean up, and correct both.
https://bugzilla.gnome.org/show_bug.cgi?id=673805
It appears that cmph library can return (n+1) when querying item not
present in its original n-item-sized set. Adjust code so that it
detects this condition and do not chase stray pointers resulting from
this bogus(?) hash result.
https://bugzilla.gnome.org/show_bug.cgi?id=675939
Fix of leak in 4c9424e18d71237f438a99bc5f2d45ae7de60b78 was a bit
overaggressive, stealing also one reference from input 'info'
argument.
Also fixes another bug in that commit - local 'func' shadowing the
return value, causing that function always returned NULL even when
some result was actually found.
https://bugzilla.gnome.org/show_bug.cgi?id=673282
- add missing colons
- invalid annotations
- invalid parameters and tags
- correct parameter name
- preserve description indentation
- no description parts
- comment end marker
- invalid empty lines
- line numbers
AnnotationParser now emits warnings which are considered as
errors by "make check" so fix those warnings...
https://bugzilla.gnome.org/show_bug.cgi?id=672254
Dealing with FFI and return values is very tricky; this API allows
sharing the bits to do it between gobject-introspection and gjs (and
potentially other FFI binding consumers).
**NOTE** I swapped the order of the arguments, under the premise that
out arguments should generally be last.
https://bugzilla.gnome.org/show_bug.cgi?id=668902
Adapted from the fixes for (see bug 665152). It makes sure values are
properly converted between glib and FFI, which is critical for big
endian architectures.
Patch adjusted to use GIArgument instead of custom union types
by Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=668902
The current source has invalid assumptions about structure alignment
that break on platforms like m68k where 32-bit integers are aligned to
16-bit only. Fix this by introducing explicit structure padding for
32-bit quantities following odd numbers of 16-bit quantities and
structure trail padding, to make the binary representation generated
by the compiler match the text of the specification exactly.
https://bugzilla.gnome.org/show_bug.cgi?id=661839
Virtual functions can definitely throw an error. Right now the
scanner omits the GError parameter for them and adds throws="1", but
g-ir-compiler ignores this.
https://bugzilla.gnome.org/show_bug.cgi?id=669332
To call a function dynamically using ffi, the caller
first has to tell ffi the size of all the input arguments
of the function. On little endian architectures (like x86_64)
specifying a size that's too large will happen to work because
of how the bits are laid out in memory. On big endian architectures,
however, specifying the wrong size can lead to reading the wrong
bits.
The function g_type_info_get_ffi_type maps input giargument types to
specific sizes. It was assuming enums were word (pointer) sized; in
fact they can be in theory any size (1,2,4,8 bytes), but in practice
in introspection (via GIArgument) as well as GValue we're limited to 4
byte enums.
This commit fixes PPC64 (big endian, 64 bit).
Signed-off-by: Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=665150
A GIBaseInfo struct can underneath either be GIRealInfo *or*
GIUnresolvedInfo if the type is GI_INFO_TYPE_UNRESOLVED. So when we
eventually free the structures slice use the correct struct type
otherwise things get unhappy.
Algorithm which detects whether argument type is pointer checks for
trailing '*' characters in c:type .gir elements. This failed if ctype
is either 'gpointer' or 'gconstpointer'. Add specific check for
gpointer/gconstpointer types when deducing pointerness of the type.
https://bugzilla.gnome.org/show_bug.cgi?id=658848
Otherwise, we fail to properly locate the typelibs, because on Windows
the value of GOBJECT_INTROSPECTION_LIBDIR depends on where Glib has been
installed. Due to the nature of how we handle software that depends on
Glib on Windows (it is recommended that each program bundles it's private
copy), we're working in a "multi-prefixed" environment. Hence the value
computed at build time will most likely not even exist at runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=620566
Complement fix for g-ir-scanner which converts every GdkRectangle
gtype to CairoRectangleInt. Make sure that C-side API is also aware
of this workaround.
Use case requiring this patch:
When binding implementation wants to get/set property, it can use either
GI-based approach (g_property_info_xxx() funcs), or just GLib facilities.
Although former is probably preferred, there are cases when latter is still
needed (e.g. gstreamer uses dynamic properties, which are not present in the
gir). In this case, binding implementation queries the type of the propertyb
(using g_object_class_find_property()), it gets GDK_TYPE_RECTANGLE,
and without the patch it cannot map it to any known type.
https://bugzilla.gnome.org/show_bug.cgi?id=655423
