It’s actually a factory method rather than a constructor, since
`GIBaseInfo` is abstract, but despite that, changing the name so it sits
inside the `GIBaseInfo` class makes sense. There is no `GIInfo` type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Even if we get warnings from the first lint check, we probably want to
see the warnings from later lint checks too, to reduce the number of
round-trips.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This will make it easier and more obvious for developers to run them
locally: I'm sure I'm not the only developer who had assumed that
`.gitlab-ci/` is private to the CI environment and inappropriate (or
perhaps even destructive) to run on a developer/user system.
The lint checks are automatically skipped (with TAP SKIP syntax) if we
are not in a git checkout, or if git or the lint tool is missing. They
can also be disabled explicitly with `meson test --no-suite=lint`,
which downstream distributions will probably want to do.
By default, most lint checks are reported as an "expected failure"
(with TAP TODO syntax) rather than a hard failure, because they do not
indicate a functional problem with GLib and there is a tendency for
lint tools to introduce additional checks or become more strict over
time. Developers can override this by configuring with `-Dwerror=true`
(which also makes compiler warnings into fatal errors), or by running
the test suite like `LINT_WARNINGS_ARE_ERRORS=1 meson test --suite=lint`.
One exception to this is tests/check-missing-install-tag.py, which is
checking a functionally significant feature of our build system, and
seems like it is unlikely to have false positives: if that one fails,
it is reported as a hard failure.
run-style-check-diff.sh and run-check-todos.sh are not currently given
this treatment, because they require search-common-ancestor.sh, which
uses Gitlab-CI-specific information to find out which commits are in-scope
for checking.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is needed because `GITypelib` is exposed in the public
libgirepository API, so needs to be introspectable.
This should fix a couple of warnings about `gi_repository_require()` and
related APIs not being introspectable as they return an unintrospectable
type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Since `GITypelib` is exposed in the public libgirepository API, it needs
to be a boxed type. So we either need to add a `copy` method to mirror
the existing `free` method, or switch to refcounting. The latter option
seems better, since a `GITypelib` contains internal state about open
`GModule`s and the semantics for copying that would be potentially
complex.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This makes them consistent with the other getter methods in
`GIRepository` which return lists/arrays. It’s useful to return the
length, as that means the caller doesn’t have to work it out by
iterating over the entire array.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Otherwise, `CFLAGS='-Wall -Werror' meson build` fails with:
...
Command line: `cc ./glib/build/meson-private/tmp7iwplrgi/testfile.c -o ./glib/build/meson-private/tmp7iwplrgi/output.obj -c -O3 -Werror -Wall -D_FILE_OFFSET_BITS=64 -O0 -std=gnu99` -> 1
stderr:
./glib/build/meson-private/tmp7iwplrgi/testfile.c: In function 'main':
./glib/build/meson-private/tmp7iwplrgi/testfile.c:83:21: error: unused variable 'y' [-Werror=unused-variable]
83 | long double y = frexpl (x, &exp);
| ^
cc1: all warnings being treated as errors
-----------
Checking if "frexpl prototype can be re-listed" compiles: NO
glib/gnulib/meson.build:316:2: ERROR: Problem encountered: frexpl() is missing or broken beyond repair, and we have nothing to replace it with
Since they are copylibs, we don’t want to diverge from upstream by
adding SPDX lines to all the files, so add them to the dep5 file
instead.
gnulib discussed adding them upstream a couple of years ago but the
discussion seemed to peter out:
https://lists.gnu.org/archive/html/bug-gnulib/2021-06/msg00004.html.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This is another way to get the file system type from `statvfs()`, newly
added in glibc 2.39
(https://lwn.net/ml/libc-alpha/38790850.J2Yia2DhmK@pinacolada/).
This hasn’t been tested with glibc 2.39 as I don’t have it, but the
change seems fairly straightforward.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It’s not suitable to use to check if your own code has already called
`g_task_return_*()`, as it doesn’t directly correlate to that.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Otherwise we would generate a multiple-inclusion guard of the
form `#ifndef __STDOUT__ ...`, which can only work for one D-Bus
interface per translation unit.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we're writing the body to standard output, we cannot know what the
filename of the corresponding header is going to be, but it seems
vanishingly unlikely that it will be either `stdout.h` (which we would
traditionally have generated) or `-.h` (which we would have generated
since !3886).
This makes some of the output snippets sufficiently short that black(1)
requires that they are folded into a single line.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In command-line tools, ordinary filenames normally do not have
special-cased meanings, so commit 3ef742eb "Don't skip dbus-codegen tests
on Win32" was a command-line API break: in the unlikely event that a
user wanted to write to a file named exactly `stdout`, this would have
been an incompatible change.
There is a conventional pseudo-filename to represent standard output,
which is `-` (for example `cat -` is a no-op filter). Adding support
for this is technically also a command-line API break (in the very
unlikely event that a user wants to write to a file named exactly `-`,
they would now have to write it as `./-`), but filenames starting with
a dash often require special treatment anyway, so this probably will not
come as a surprise to anyone.
When the output filename is `-` we don't want to use `#ifdef _____` as
a header guard, so special-case it as `__STDOUT__` as before.
Signed-off-by: Simon McVittie <smcv@collabora.com>
It’s reasonable for the `main()` function in a test suite to pass
ownership of some test data to `g_test_add_data_func_full()`, along with
a `GDestroyNotify`, and rely on GTest to free the data after all tests
have been run.
Unfortunately that only worked if the test was run, and not skipped
before its test function was called. This could happen if, for example,
it had `/subprocess` in its path.
Fix that by always freeing the test data. This required reworking how
tests are skipped, slightly, to bring all the logic for that within
`test_case_run()`, so that it could always handle the memory management.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3248
It’s more helpful to always register the test, even if it’s normally
skipped, since then the skip is recorded in the test logs so people can
see what’s ‘missing’ from them.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fix the declaration and documentation of
`gi_object_info_find_method_using_interfaces()` and
`gi_object_info_find_vfunc_using_interfaces()`. The documentation was
wrong when I wrote it: the value returned is the object or interface
which declares the method or vfunc, not the one which implements it.
The returned declarer info may be a `GIObjectInfo` or a
`GIInterfaceInfo`. Since those two types have no subtype relation
between them, the return type has to be changed to `GIBaseInfo`. Using
`GIObjectInfo` would have been fine in girepository-1.0 because all
`*Info` types were aliases of each other — but since the move to
`GTypeInstance` this is no longer true.
A unit test will be in the following commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3246
This covers all the API changes from girepository-1.0 to
girepository-2.0 so far.
It was generated by manually looking through the changes in `git diff
af36393e6.. -- girepository/*.h`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
The function arguments index_ and length could lead to a sum which is
larger than G_MAXUINT, possibly leading to out of boundary accesses
in array_remove_range functions.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Fixes: #3240
It's not obvious why we wouldn't use g_quark_try_string(). Add a code
comment that this is intentional and a reference for how to find out
more.
Also, fix typo in another code comment.
