The C compiler will pick an enumeration type that accomodates the specified
values for the enumeration, so ignoring 64-bit enumerations, we can
have enumeration values from MININT32 to MAXUINT32. To handle this properly:
- Use gint64 for holding eumeration values when scanning
- Add a 'unsigned_value' bit to ValueBlob so we can distinguish the
int32 vs. uint32 cases in the typelib
- Change the return value of g_value_info_get_value() to gint64.
https://bugzilla.gnome.org/show_bug.cgi?id=629704
Previously we just were sloppy and didn't bother to accurately compute
signed/unsigned for enumeration types. But since we expect bindings
to decode a field value or function return value from an integer to
an enumeration they have know whether an integer value is
0xffffffff or -1, so we need to do the full computation.
https://bugzilla.gnome.org/show_bug.cgi?id=629704
Commit f97cc8687469f25752f79275 broke the lookup in
g_irepository_get_info; the passed offset is 0-based, then
we convert it to 1-based (and then back to 0 later...which needs
to be fixed).
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.
This helps us avoid a problematic case where in say jhbuild, using
a system (/usr/lib) glib, adding in -l girepository-1.0 will inject
-L /path/to/builddir, when we don't want that.
https://bugzilla.gnome.org/show_bug.cgi?id=630342
Documentation says about g_vfunc_get_offset():
"Obtain the offset of the function pointer in the class struct.
The value 0xFFFF indicates that the struct offset is unknown."
But g-ir-compiler did set the value to 0 when the offset is unknown.
This patch fixes it.
https://bugzilla.gnome.org/show_bug.cgi?id=628270
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.
Rather than have the scanner/parser handle both e.g. "glong" and
"long", simply use the GLib types everywhere.
This commit adds TYPE_LONG_LONG and TYPE_LONG_DOUBLE to the
scanner types; however, rather than add them to the typelib,
they're just marked as not-introspectable.
The reason for the warning was that g_irepository_get_version() expects
the typelib to be already loaded, but enumerate_version() can be called
on typelibs that are not.
Logically speaking, the already loaded version of a namespace is part of
the currently available versions, and can be forgotten if we only
consider the versions available in GI_TYPELIB_PATH, as it could have
been loaded using g_irepository_require_private().
As a side effect, it meant that bindings relying on enumerate_version()
(like pygobject) were not able to require private versions through their
classical requirement scheme.
This patch fixes it by adding the loaded version to the unsorted list of
available versions returned by g_irepository_enumerate_versions()
This patch also uses g_list_prepend() instead of g_list_append() in that
function.
https://bugzilla.gnome.org/show_bug.cgi?id=625983
We never actually include multiple modules in the compiler,
so just nuke that. Also rather than passing around GIrModule
consistently pass around a GIrTypelibBuild structure which
has various things.
This lets us maintain a stack there which we can walk for
better error messages.
Also, fix up the node lookup in giroffsets.c; previously
it didn't really handle includes correctly. We really need to
switch to always using Foo.Bar (i.e. GIName) names internally...
We didn't show the right error message if we failed to find
the symbol; fix this by removing error printing from the
middle of the dumper, and add it correctly to the toplevel
dump entry point.
Entries in the GI_TYPELIB_PATH environment variable are added to the
global search path in reverse order - instead, add entries in the
same order in which they are specified.
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.
