Add "n_field_callbacks" to ObjectBlob which represents the number of object
fields which are also callbacks. This a allows a constant time computation
for accessing sections after fields. Track writing of this field by passing
an extra argument through the girnode writers recursive call structure. This
essentally reverts a portion of commit 7027bb256d0d1ab which added a linear
time computation for accessing sections after fields.
Update typelib validator to also ensure n_field_callbacks is properly set.
https://bugzilla.gnome.org/show_bug.cgi?id=700338
This includes config.h in all the C-sources of girepository so that we can
get the correct export directive from config.h during compile time and
therefore export the symbols as necessary, like what GLib and GTK+ is
currently doing.
https://bugzilla.gnome.org/show_bug.cgi?id=732669
Use ParseState enum instead of a boolean for the ParseContexts embedded_type
flag. This allows specific tracking of the embedded type currently being
parsed which can now either be STATE_STRUCT_FIELD or STATE_CLASS_FIELD (or
allow for future expansion). Add ParseState::STATE_NONE as the default for
this field.
Fix GObject FieldBlob validation to take into account the sizeof
CallbackBlobs (copied from the struct validator).
Add static g_object_info_get_field_offset which parallels
g_struct_info_get_field_offset which is needed since callback fields may
vary in size.
https://bugzilla.gnome.org/show_bug.cgi?id=725198
- require GTK-Doc 1.19
- remove sgml mode
- automatically generate gi.types (needs GTK-Doc 1.19)
- fix https://bugzilla.gnome.org/show_bug.cgi?id=700025
[WIP] - rearange sections a bit
[WIP] - add gi-building, gi-programming sections
[WIP] - mark missing docs with TODO, which is only marginaly
better than nothing but at least can be grepped :)
https://bugzilla.gnome.org/show_bug.cgi?id=571648
When g_irepository_find_by_gtype() doesn't succeed on a simple prefix
match (the current 'fastpass' mechanism), it ends up taking a
considerable amount of CPU time, traversing the contents of all typelibs.
I imagine that the reasons to have the exhaustive search fallback are
not as strong as they used to be. For example, the case mentioned
(Clutter including Cogl) no longer seems to be true.
Also, typelibs (as generated by g-ir-scanner) now provide
comma-separated C prefix info for cases when the typelib includes
introspection info for multiple prefixes. For example, the Sugar typelib
has a c_prefix string of Sugar,EggSM,Gsm,Acme. So I imagine there are
not many remaining justified cases where the exhaustive search is needed.
With that in mind, I found two ways to optimize this function:
1. Support comma-separated C prefixes
2. Don't bother with an exhaustive search if we did find a typelib
claiming support for the prefix. For example, if we're looking for
GdkDeviceManagerXI2 (currently non-introspectable) and we already found
typelib files providing the 'Gdk' prefix that didn't offer this, lets
not bother with the exhaustive search, we aren't going to find anything.
Previously we would require applications that shipped with private
typelibs to add the private path to LD_LIBRARY_PATH, or to have a
launcher binary with the right RPATH.
Now they can just call GIRepository.prepend_library_path() before
they access the module.
https://bugzilla.gnome.org/show_bug.cgi?id=694485
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
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
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
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
Use the internal perfect hashing API to add an index to the directory.
To support this, add the notion of additional "sections" to the
typelib. A section index is inserted between the header and the
directory.
https://bugzilla.gnome.org/show_bug.cgi?id=554943
This is a cleanup patch in preparation for future indexing
patches.
The lookup code was a mess trying to mash in the 3 different
cases of name, GType, and index into one mega-function.
Split it up properly, and move the core typelib internal-scanning
bits into gitypelib.c where it belongs.
Previously we bombed out if the minor version didn't match what
we expected; this was silly since the whole point of the minor
version is to enumerate compatible changes.
One of the first big changes in this rewrite is changing the Type
object to have separate target_fundamental and target_giname properties,
rather than just being strings. Previously in the scanner, it was
awful because we used heuristics around strings.
The ast.py is refactored so that not everything is a Node - that
was a rather useless abstraction. Now, only things which can have
a GIName are Node. E.g. Type and Field are no longer Node.
More things were merged from glibast.py into ast.py, since it isn't
a very useful split.
transformer.py gains more intelligence and will e.g. turn GLib.List
into a List() object earlier. The namespace processing is a lot
cleaner now; since we parse the included .girs, we know the C
prefix for each namespace, and have functions to parse both
C type names (GtkFooBar) and symbols gtk_foo_bar into their
symbols cleanly. Type resolution is much, much saner because
we know Type(target_giname=Gtk.Foo) maps to the namespace Gtk.
glibtransformer.py now just handles the XML processing from the dump,
and a few miscellaneous things.
The major heavy lifting now lives in primarytransformer.py, which
is a combination of most of annotationparser.py and half of
glibtransformer.py.
annotationparser.py now literally just parses annotations; it's
no longer in the business of e.g. guessing transfer too.
finaltransformer.py is a new file which does post-analysis for
"introspectability" mainly.
girparser.c is fixed for some introspectable=0 processing.
Take a GError * for typelib loading code, validate the header. This
fixes bizarre errors from gjs where g_irepository_require would happily
load old typelibs.
Previously we had both e.g. GI_TYPE_TAG_LONG and GI_TYPE_TAG_INT64,
but in fact the typelib is already machine-specific, so it makes sense
to just encode this as a fixed type. The .gir remains abstract.
We also remove size_t from the typelib; one would never want to treat
it differently than an integer.
time_t is removed as well; while bindings like gjs had special handling
to turn it into e.g. a JS Date object, I don't think we should encourage
people to use these POSIX types in their API. Use GTimeVal or the like
instead.
Because the typelib is now really machine-specific, we need to remove
the -expected.tgirs from git. (We could potentially add a check
which wasn't just a literal diff later)
https://bugzilla.gnome.org/show_bug.cgi?id=623774
This patch adds support for instantiable fundamental object types,
which are not GObject based. This is mostly interesting for being
able to support GstMiniObject's which are extensivly used in GStreamer.
Includes a big test case to the Everything module (inspired by
GstMiniObject) which should be used by language bindings who wishes to
test this functionallity.
This patch increases the size of the typelib and breaks compatibility
with older typelibs.
https://bugzilla.gnome.org/show_bug.cgi?id=568913
* girepository/gitypelib.c: Don't complain about constructors
returning types other than objects or interfaces if the container
type isn't an object or interface itself.
* giscanner/glibtransformer.py: Don't give up parsing a method just
because it's in the GLib namespace.
https://bugzilla.gnome.org/show_bug.cgi?id=621069
