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>
This effectively reverts commit 0910e2f6ad. I thought that `GIInfoType`
was decoupled from `GITypelibBlobType`, but it turns out that
`girepository.c` calls `gi_info_new_full()` with blob types, implicitly
converting them to info types.
This was causing anything with a type higher than the `INVALID_0` value
to be loaded as the wrong type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Otherwise there’s no obvious suitable return value to return when the
union is *not* discriminated.
This is an API break, but libgirepository has not been in a stable
release yet, so that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
