| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
So it can be used for invoking callbacks
https://bugzilla.gnome.org/show_bug.cgi?id=663052
Signed-off-by: Martin Pitt <martinpitt@gnome.org>
|
|
|
|
|
|
| |
Signed-off-by: Michel Dänzer <michel@daenzer.net>
https://bugzilla.gnome.org/show_bug.cgi?id=668902
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=661951
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=669317
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
As an analogue to g_object_info_find_method_using_interfaces, add a
new API so that we can find a vfunc using the same strategy.
|
|
|
|
|
| |
This is a new method designed to make a GIFunctionInvoker for
any GICallableInfo*, for bindings to use.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
These variables are unused.
https://bugzilla.gnome.org/show_bug.cgi?id=665249
|
|
|
|
|
|
|
| |
g_slice_free complains when you pass it a pointer of a different type
than it was expecting, like it should.
https://bugzilla.gnome.org/show_bug.cgi?id=665249
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
error was not set.
Noticed the segmentation fault while using Vala to generate a .gir, a bug has
been filed tomake sure Vala doesn't export gir symbols outside of a namespace
(see https://bugzilla.gnome.org/show_bug.cgi?id=661952)
https://bugzilla.gnome.org/show_bug.cgi?id=661951
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=654069
|
|
|
|
|
|
| |
It was returning the wrong data.
https://bugzilla.gnome.org/show_bug.cgi?id=659749
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Windows.
So only include it when WIN32 is not defined.
https://bugzilla.gnome.org/show_bug.cgi?id=620566
|
|
|
|
| |
Usage: ./_build/gi-dump-types g_object_get_type
|
|
|
|
| |
While we're here move config.h to the top for consistency.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This uses the same backcompat machinery that was introduced for static
methods for non-class types, so this change does not break users of the
existing presentations.
New libgirepository API:
g_enum_info_get_n_methods
g_enum_info_get_method
https://bugzilla.gnome.org/show_bug.cgi?id=656499
|
|
|
|
|
|
| |
This adds all GSignalFlags into the gir.
https://bugzilla.gnome.org/show_bug.cgi?id=656457
|
|
|
|
|
|
|
|
| |
Add a method to look up a GIEnumInfo given its associated error quark.
Based on a patch from Colin Walters.
https://bugzilla.gnome.org/show_bug.cgi?id=602516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of storing the name of the function to call to get the
error quark, store the string form of the error quark, which
we derive from the introspection binary during scanning.
Update EnumBlob and GIEnumInfo to include the new information.
This will allow determining a back-mapping from error quark
to error domain without having to dlsym() and call all the
known error quark functions.
Based on earlier patches from Owen Taylor and Maxim Ermilov.
https://bugzilla.gnome.org/show_bug.cgi?id=602516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous ErrorDomain blob was never actually scanned or used, and
it was kind of a lame API conceptually.
To keep some compatibility, rather than removing the enumeration
values, rename them to _INVALID, and don't bump the typelib version.
This should in theory allow a new libgirepository to read an old
typelib.
Based on a patch from Colin Walters
https://bugzilla.gnome.org/show_bug.cgi?id=602516
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=652625
|
|
|
|
|
|
|
| |
g_callable_info_prepare_closure() allocates memory for the argument
types in the ffi_cif, so we need to free it.
https://bugzilla.gnome.org/show_bug.cgi?id=652954
|
|
|
|
|
|
|
|
|
|
|
| |
Change the special code for handling GObject and GInitiallyUnowned
so that it exposes GParamSpec as a class, and it allows GVariant to
have a GType without using the deprecate g_variant_get_gtype.
It is a sort of ABI break, in that new typelibs won't work with
previous versions of libgirepository.
https://bugzilla.gnome.org/show_bug.cgi?id=646635
|
|
|
|
|
|
|
|
|
|
| |
We need to distinguish inline arrays inside structures, and arrays
that are pointers and annotations, and we can do it with
g_type_info_is_pointer(), setting it to FALSE for fixed size arrays.
As a side effect, (array fixed-size=N) on a pointer type has no longer
the expected result.
https://bugzilla.gnome.org/show_bug.cgi?id=646635
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This was discussed in bug 649657.
https://bugzilla.gnome.org/show_bug.cgi?id=649657
Signed-off-by: David Zeuthen <davidz@redhat.com>
|
|
|
|
|
|
| |
Also add a test case.
https://bugzilla.gnome.org/show_bug.cgi?id=640468
|
|
|
|
|
|
|
|
| |
This bug was introduced with
http://git.gnome.org/browse/gobject-introspection/commit/?id=36aa515f1036978ced8d4ffb808260844f7229e0
due to rename of c:prefix to c:identifier-prefixes.
https://bugzilla.gnome.org/show_bug.cgi?id=640264
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=644749
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Flags and enums with a GType have a value_nick and value_name
strings available in the class struct. But for flags and enums
without GType, we need to get this information from introspection.
g_base_info_get_name() gives the string for value_nick. In the GIR,
the attribute "c:identifier" is the string neede for value_name.
This patch adds the "c:identifier" from GIR to the typelib for all
flags and enum values. It can be retireved using
g_base_info_get_attribute(info, "c:identifier").
https://bugzilla.gnome.org/show_bug.cgi?id=642757
|
|
|
|
|
|
|
|
| |
Different types of array have different type nodes, so they should
produce different keys in the cache of already seen type nodes, to
avoid turning a GByteArray into a reference to a GPtrArray.
https://bugzilla.gnome.org/show_bug.cgi?id=642300
|
|
|
|
|
|
|
| |
The argument was called 'ctx' but the macro was using 'context'.
This wasn't causing the build to fail because the variable
'context' was already defined in all the scopes where this macro
was used.
|