| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Add an annotation tag "Value:" which can be used on
constants to override the value.
|
|
|
|
| |
Fixes the test when running uninstalled.
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This applies mainly to GValue, which is defined as:
struct _GValue
{
/*< private >*/
GType g_type;
/* public for GTypeValueTable methods */
union {
gint v_int;
guint v_uint;
glong v_long;
gulong v_ulong;
gint64 v_int64;
guint64 v_uint64;
gfloat v_float;
gdouble v_double;
gpointer v_pointer;
} data[2];
};
Previously, the scanner did not understand the array of unions. This
resulted in g_struct_info_get_size returning an incorrect size for
GValue (at least on 32bit systems).
Fix this by making up a separate union declaration for the GIR that can
be referenced by the array.
https://bugzilla.gnome.org/show_bug.cgi?id=657040
|
|
|
|
|
| |
For gjs we want to switch to using introspection data for signals, and
the "notify" signal being missing from GObject was a problem.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=620566
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=620566
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=658075
|
|
|
|
| |
The new missing-element-type warning triggers for these.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 81abc2eb63317003a11d1484e84698a37e8ec035 tries harder to keep
the c:type if it was overriden by a (type) annotation. However, the
_resolve() function was also called for (element-type), which had
undesirable effects - we'd copy the container c:type to the element
type.
Fix this by splitting out the c:type preservation to only happen when
processing toplevel types.
https://bugzilla.gnome.org/show_bug.cgi?id=656931
|
|
|
|
|
|
| |
While looking for a different bug, I noticed that the introspectable
pass lists was missing GSList. And the warning was never set up
to fire anyways. Fix it and add a test.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use automake's check_ prefix and avoid putting anything nontrivial in
BUILT_SOURCES so that tests are build only on make check.
The dummy -rpath in AM_LDFLAGS in tests/scanner/Makefile.am is needed to
force libtool to build shared libraries for check_LTLIBRARIESS targets
(automake builds check_LTLIBRARIES as static by default); see
http://lists.gnu.org/archive/html/automake/2005-10/msg00107.html
https://bugzilla.gnome.org/show_bug.cgi?id=657066
|
|
|
|
|
| |
They don't work for multiple reasons, and there is still debate
about how the formatting etc. will work.
|
|
|
|
|
| |
g-ir-scanner now warns for invalid (element-type) annotations
in GPtrArray and in GByteArray. Test that.
|
|
|
|
| |
so we don't generate the test docs when doing a plain build
|
|
|
|
|
|
|
|
|
| |
Similarly to GPtrArrays, GByteArrays can only contain bytes. Emit
a warning if an inconsistent (element-type) is placed, and ensure
that the default is guint8 if nothing is added. This way bindings
can support GByteArrays without special casing them.
https://bugzilla.gnome.org/show_bug.cgi?id=652753
|
|
|
|
|
|
|
|
|
| |
It should be safe for bindings to assume that GPtrArrays hold only
pointers (or values as big as it), so there is no need to go through
hoops for converting smaller integers when marshalling.
Libraries that need arrays of integers should use GArray.
https://bugzilla.gnome.org/show_bug.cgi?id=652753
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
If we're done parsing parameters, previously we would simply eat lines that looked like
@foo: blah blah
Example is in gtkcssprovider.c.
https://bugzilla.gnome.org/show_bug.cgi?id=656504
|
|\
| |
| |
| |
| |
| | |
Conflicts:
.gitignore
tests/scanner/Regress-1.0-expected.gir
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
This adds all GSignalFlags into the gir.
https://bugzilla.gnome.org/show_bug.cgi?id=656457
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
For generating documentation, we actually want to preserve these.
https://bugzilla.gnome.org/show_bug.cgi?id=656389
|
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|