If a <GType invalid> (that's the way it appears in python's debugger) is
returned, `g_type_name` returns NULL. This
function therefore returns NULL at this time
as subsequent calls to `strlen( data->gtype_name)` segfault.
There are notably 4 classes of GTypes where a girepository lookup
might fail:
- GTypes from private interfaces in public objects (eg. MetaCullable in
mutter)
- GTypes for private base objects with public interfaces (eg. GLocalFile
in GLib)
- GTypes registered from the language, and presumably not coming from the
GIR
- GTypes of objects/interfaces that we didn't load a typelib for
It is moot to look for those over and over again, and a full lookup can
be taxing if looking up for a method/property on objects with those
characteristics.
It seems we can cache the misses too, so next lookups are just as quick
as an introspected GType. The cache is invalidated after loading new
typelibs, in case some of the previously missed GTypes is now properly
introspected.
In g_irepository_get_object_gtype_interfaces(), returning the address of
the first GIBaseInfo* does not work reliably, because the GIBaseInfos
are not necessarily stored contiguously. So the second and subsequent
ones might be garbage.
Instead, return the address of the array of GIBaseInfo pointers.
Add a test that verifies the functionality, as well.
This is unfortunately an API and ABI break.
If g_mapped_file_new fails, then `version` will be freed, but it was
already added to the hash table. This means there could be a
use-after-free while doing a lookup on the hash table the next time.
If a transitive dependency appears twice, the original pointer will be
removed from the hash table. Since these names were created by
g_strsplit, they need to be freed, or they will leak.
Bindings in some cases need to look up information from a GType
dynamically. Support that better by supplying a cache for this
information.
(Rebased and versioning / gtk-doc stuff added by Philip Chimento.)
Closes#38.
See gjs#55.
Move things around and rename things until gtk-doc is happy.
This also moves the "Since" annotations to the next stable releases and
adds version added info for g_callable_info_get_instance_ownership_transfer()
and g_struct_info_find_field().
Where it's easy add dummy args to match the cast; where the target is a subset just
prevent the warning with a cast to void*.
Provide a real copy function for the boxed type code in regress_foo.
This code is never executed afaics, but why not.
This reverts commit e81c4681cc88a00fcd841c5a68d860d3714b55d7
The GI_TYPELIB_PATH envvar will still allow overriding the default
typelib dir (based on gobject-introspection libdir), but applications
will have the last say about typelib lookup directories. The resulting
lookup order is now:
- Paths added through g_irepository_prepend_search_path()
- Paths in GI_TYPELIB_PATH
- The default gobject introspection lookup dir
This makes g_irespository_prepend_search_path() work as announced
despite environment variables. If any application was relying on
GI_TYPELIB_PATH overriding the paths of this function call (for e.g.
make check, or to be able to run code inside the project tree), it
is encouraged to set up a similar envvar for their application specific
lookup dir, or perform this override through other means.
https://bugzilla.gnome.org/show_bug.cgi?id=765735
This reverts commit 98bb6c91b710a95efe4cfeb303daeec3381b9c98.
It breaks programs simply executed *transitively* from a setuid
binary like the dbus daemon launch helper.
https://bugzilla.redhat.com/show_bug.cgi?id=1285991
Conflicts:
girepository/girepository.c
We know of at least one privilege escalation path via
`GI_TYPELIB_PATH`. I don't want to audit for others. If someone
shows up with a use case we can talk.
https://bugzilla.gnome.org/show_bug.cgi?id=755472
This optimization is bugged and broken in the case of certain
libraries. GNOME uses a lot of prefixes with "G", so we'll almost always
have found the prefix.
This is specifically a problem for something like GXml.xDocument, which
uses a type name starting with a lower-case letter, which fools the
prefix logic, but we're also fooled by the "G" appearing in GLib and
Gio.
A more sophisticated version of this check would have three passes:
check prefix with type-case, check prefix without type-case, global
search, but this is an edge case and it doesn't feel worth it to write.
g_irepository_get_dependencies() is supposed to return the transitive
closure of all dependencies of the given namespace. However, it just
loads the dependencies field from the typelib, which is supposed to only
list immediate dependencies.
Introduce a new g_irepository_get_immediate_dependencies() which does
this, and rewrite g_irepository_get_dependencies() to build the
transitive closure of all its namespace dependencies. This does not
require loading any new typelibs, as the transitive closure of
dependencies should already have been loaded by g_irepository_require()
or g_irepository_load_typelib().
https://bugzilla.gnome.org/show_bug.cgi?id=743782
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
- 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.
- 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
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
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
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.
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.
