In macOS compilation fails with the following error:
```
In file included from ../girepository/tests/autoptr.c:23:
../girepository/girffi.h:30:10: fatal error: 'ffi.h' file not found
```
Relocation is a common scenario in macOS applications and frameworks.
This commit provides a mechanism to support relocations by inferring
the typelib dir from the path of the loaded image libgirepository-1.0.dylib.
For historical reasons, some doc blocks are included in an ancillary
file. Add it to the list of sources parsed by g-ir-scanner, to increase
the coverage of various macros.
Fixes: #3372
It's just better than a list of strings for various reasons, but mostly
here it allows also to avoid copying the lists but making the
ownership clearer through references
In this way the module can survive without that the parser is fully
alive.
At the moment a module has not a ref-count system, but this makes things
clearer when we return the module from a parser.
In case the node was pushed to a non-empty node stack, then we were not
tracking it in the entries list, and so nothing was freeing it on
destruction.
As per this, once parsing is done, we can free it or we'd leak.
The compiler code was full of leaks and nothing really checked on them.
While it's not a big deal per se, per the nature of it, it's still
better to ensure that memory management is well done so that there are
no problems when using it with sanitizers.
So, the source of the problems was not freeing the parser, but that
wasn't enough, more to come...
We are overriding the default g-ir-compiler for local usage, but this
is not actually happen since that's computed while parsing introspection
So generate the compiler as first thing, then in case handle the
introspection data
As with the previous two commits, the results of calling
`gi_repository_get_loaded_namespaces()` were previously
non-deterministic due to being generated by iterating over a hash table,
which has a non-deterministic iteration order.
Fix that by using the new `ordered_typelibs` and `ordered_lazy_typelibs`
arrays to provide deterministic ordering.
At the same time, significantly reduce the number of allocations needed
to build the return value — previously the results would be built as a
linked list before being turned into an array. The linked list is now
banished to history.
Add some more unit tests to maximise test coverage of this method.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3303
As with the previous commit, finding a `GIBaseInfo` matching the given
error domain was non-deterministic because it iterated through a hash
table of typelibs. Hash table iteration is non-deterministic.
Change the method to instead use the `ordered_typelibs` and
`ordered_lazy_typelibs` arrays to give deterministic iteration order.
Add a unit test, although it can’t test the interesting case of an error
domain which is present in both `GioUnix`/`GioWin32` and `Gio`, because
no such error domain exists.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
When faced with a `GType` which is present in multiple typelibs, the old
implementation was not deterministic, as it iterated over a hash table
of typelibs. The iteration order of a hash table is not deterministic.
Use the new `ordered_typelibs` and `ordered_lazy_typelibs` arrays to
iterate instead, making the order deterministic.
Add a unit test to check this. In particular, to check that symbols
which are present in both `Gio` and `GioUnix` are correctly resolved as
being from `GioUnix`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
The iteration code used `g_string_overwrite_len()` to try and simplify
buffer allocation and growth, but seemingly forgot to handle the fact
that it doesn’t nul-terminate what it overwrites: the method is intended
to be used to splice bits into longer strings, not to overwrite an
entire nul-terminated string.
This meant that when iterating over a comma-separated `c_prefix` like
`GUnix,G`, on the second iteration `g_string_overwrite_len()` would be
used to write `G` into index 0 of the already-set `GUnix` string in the
buffer, leading to the first iteration happening all over again and the
`G` prefix being ignored.
This led to symbols failing to be matched to the `GioUnix` typelib, even
though they should have been.
This will be checked by a test in the following commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
There are various places where the set of typelibs is iterated over or
returned in an ordered way. In order to keep results deterministic and
reproducible, we need to keep this set ordered.
Keep a `GPtrArray` of the typelibs (one for fully-loaded ones and one
for lazy ones) alongside the existing hash tables. This will be used for
iteration in the next few commits.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
The type used when declaring a bitfield member of a struct doesn't
affect the amount of space allocated for it - only whether it's signed
or unsigned. In standard C99 (6.2.7.1), only _Bool, signed int and
unsigned int or typedefs to them are allowed as bitfield types, but GCC
allows other integer types as an extension.
In this case, the GIBaseInfo and GIBaseInfoStack structs are meant to
have identical layout. However, type_is_embedded was declared as an
unsigned bitfield in the former and a uint32_t in the latter. This was
harmless on most platforms because the following member is an aligned
pointer, but (for example) on m68k-linux-gnu pointers only need to be
16-bit aligned, so GCC only allocates 16 bits for the bitfield.
Change the type in the declaration to unsigned int, and add an padding
bitfield following it to ensure there's space for 32 bits on all
platforms in the future.
Signed-off-by: Adam Sampson <ats@offog.org>
It's an array containing the list of sanitizers in use, normally it
contains a value, but in some cases may have more than one (e.g.
'address' and 'undefined').
And so use it to avoid repeated checks
Tests may have runtime dependencies that are related to the typelib
dependencies, so we need to satify them or the tests will fail at
runtime if we're not building their prerequisite for other reasons.
That's saying that the tests are currently failing when explicitly
running as standalone in meson.
Co-Authored-By: Philip Withnall <philip@tecnocode.co.uk>
It’s very obviously a false positive, as `str` has been added to on the
previous line, so can’t be `(void *) 0`. Not sure what scan-build is
thinking.
I’d rather not have this assertion (it doesn’t help the programmer’s
understanding of the code), but I would also rather have scan-build
running with no warnings so that it can helpfully catch newly-introduced
errors in future.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
Basically various trivial instances of the following MSVC compiler
warning:
```
../gio/gio-tool-set.c(50): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
There is a meson option (gir_dir_prefix), but without being passed in here
the files would always get installed into the default location (datadir).
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
All of the indications in the surrounding code are that `node` should
never be `NULL`, but the error handling for it did actually allow it to
be `NULL` iff its `parent` was also `NULL`.
That made scan-build (kind of legitimately) warn about `NULL` pointer
dereferences of `node`.
Avoid that by unambiguously using an assertion to prevent `NULL` nodes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
scan-build thinks that the `atypes` array is leaked, but it’s not.
Ownership is transferred into the `ffi_cif` structure, and it’s
eventually freed in `gi_callable_info_destroy_closure()`.
Try and help the static analysis by adding an explicit ownership
transfer annotation. It probably won’t help.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
We don't actually need to use the Meson-detected size macros here,
because the result of `sizeof()` is an integer constant expression.
No functional change.
Signed-off-by: Simon McVittie <smcv@collabora.com>
g-ir-scanner currently maps these to lower-level types at scan time by
assuming that time_t is an alias for long, off_t is an alias for size_t
and so on. This is not always accurate: some ILP32 architectures have
64-bit time_t (for Y2038 compatibility) and 64-bit off_t (for large file
support), and that mismatch is tracked as GNOME/gobject-introspection#494.
One option for resolving this g-ir-scanner bug is to have it pass these
types through to the GIR XML, and teach g-ir-compiler and its replacement
gi-compile-repository to convert them to the corresponding concrete
type tag, as they already do for abstract types such as `long long` and
`size_t`.
Loosely based on GNOME/gobject-introspection!451 by Shuyu Liu.
Co-authored-by: Shuyu Liu <liushuyu011@gmail.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't actually need to use the results of configure-time checks here:
sizeof is a perfectly reasonable integer constant expression, so we can
use that directly.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise, correct invocation isn't clear from the --help output.
This does not introduce new translated strings: FILE was already
translated.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we don't do this, the --help text is formatted as though the option
did not expect an argument.
This does not introduce new translated strings: DIRECTORY was already
translated.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The code and strings are the same, so let’s simplify things and reduce
LoC for no functional change.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
