Python 3.6 and 3.7 officially reached EOL on 2021-12-23 and 2023-06-27
respectively, and `markdown-stubs/core.pyi` is no longer compatible
with Python older than 3.8, causing a CI failure.

Resolves: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/496


Signed-off-by: Simon McVittie <smcv@debian.org>

Signed-off-by: Simon McVittie <smcv@debian.org>

Currently it is not.

Signed-off-by: Simon McVittie <smcv@debian.org>

Makes it easier to find, and easier to link.

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.

Equivalent to https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3966


in GLib.

Signed-off-by: Simon McVittie <smcv@debian.org>

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. Equivalent to
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3970

 in GLib.

Signed-off-by: Simon McVittie <smcv@debian.org>

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).

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`.

This is a gobject-introspection equivalent of
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3967 and
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3972, which in
turn are based on part of GNOME/gobject-introspection!451 by Shuyu Liu.

Helps: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/494


Co-authored-by: Shuyu Liu <liushuyu011@gmail.com>

Zixing Liu authored Mar 11, 2024 and Simon McVittie committed Mar 18, 2024

g-ir-scanner previously mapped these to lower-level types at scan time
by assuming that time_t is an alias for long and off_t is an alias
for size_t.  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).

[smcv: Added longer commit message]
Resolves: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/494


Co-authored-by: Simon McVittie <smcv@debian.org>
Signed-off-by: Simon McVittie <smcv@debian.org>

Signed-off-by: Simon McVittie <smcv@debian.org>

There is currently no test coverage for async new functions.
(as is generated with gdbus-codegen)

This commit adds a test case for that.

async _new functions get treated as static methods, while
their finish functions get treated as constructors.

That leads to g-ir-scanner unable to match them up, causing
warnings like this for gdbus codegen'd code:

 Warning: Namespace: Couldn't find 'new_finish' for the corresponding async function: 'new'

This commit merges static methods and constructors together for
the purposes of finding async/finish pairs.

The location of the symbols has changed.