Similar to g_source_set_static_name, this avoids
strdup overhead for debug-only information in
possibly hot code paths.
We also add a macro wrapper for g_task_set_name that
uses __builtin_constant_p to decide whether to use
g_task_set_name or g_task_set_static_name.
We already set names on most sources, this
one was just forgotten. This lets us set
a static name, and prevents g_task_attach_source
from setting a non-static one.
The platform-specific predefined macros provided by various compilers
sometimes capture subtle differences of meaning, like the distinction
between the Linux kernel and a glibc-based (GNU/Linux) user-space.
It would be difficult to capture those subtleties in GLib-specific
convenience macros, particularly for platforms that we don't use
ourselves.
Instead, recommend that anyone who is already writing platform-specific
code should use the platform-specific predefined macros directly.
Alternative to !2986.
Signed-off-by: Simon McVittie <smcv@collabora.com>
`g_app_info_launch_default_for_uri_async()` has already returned by this
point, so waiting a long time is not really going to help.
Wait for 3× as long as the successful case took, which should allow for
long enough to catch true negatives, with a bit of variance.
On my system, this means waiting for about 14ms, rather than the 100ms
which this previous slept for. This speeds the test up by about 5%.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Given that it can be computed using an error-prone strings comparisons it
is better to provide a variable everywhere, so that we don't have the
risk of comparing values that are always false.
We have tests that are failing in some environments, but it's
difficult to handle them because:
- for some environments we just allow all the tests to fail: DANGEROUS
- when we don't allow failures we have flacky tests: A CI pain
So, to avoid this and ensure that:
- New failing tests are tracked in all platforms
- gitlab integration on tests reports is working
- coverage is reported also for failing tests
Add support for `can_fail` keyword on tests that would mark the test as
part of the `failing` test suite.
Not adding the suite directly when defining the tests as this is
definitely simpler and allows to define conditions more clearly (see next
commits).
Now, add a default test setup that does not run the failing and flaky tests
by default (not to bother distributors with testing well-known issues) and
eventually run all the tests in CI:
- Non-flaky tests cannot fail in all platforms
- Failing and Flaky tests can fail
In both cases we save the test reports so that gitlab integration is
preserved.
We have gnulib warnings in windows under clang:
../glib/gnulib/vasnprintf.c:2429:21: warning: variable 'flags' set but not
used [-Wunused-but-set-variable]
int flags = dp->flags;
^
../glib/gnulib/vasnprintf.c:4853:19: warning: unannotated fall-through
between switch labels [-Wimplicit-fallthrough]
case TYPE_LONGINT:
^
See: https://gitlab.gnome.org/3v1n0/glib/-/jobs/2361750
C99 does not actually guarantee that the platform has 8-, 16-, 32- and
64-bit types, but it does guarantee that if the platform has them, then
(u)intN_t are defined to be examples of those types.
GLib goes beyond what C99 guarantees, and requires 8-, 16-, 32- and
64-bit types; combining that with C99's requirements means we can
assume that int8_t, uint64_t, etc. all exist.
Unfortunately, we cannot guarantee that GLib and the C99 toolchain have
chosen the *same* fixed-size type: for example, on a typical ILP32
or LLP64 platform like Windows or 32-bit Linux, each 32-bit type could
either be int or long, while on a LP64 platform like 64-bit Linux,
each 64-bit type could either be long or long long. The in-memory
representation is the same either way, but the choice of underlying type
matters when building printf format strings or issuing compiler warnings.
As a result, we can't just typedef gint32 as int32_t and so on.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
The important thing here is that we can't arbitrarily mix these, even if
they will often have the same in-memory representation.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
These have a status similar to size_t: they're Standard C types and
straightforward to use in portable code this decade, but we can't
guarantee that we have chosen the same underlying type that the platform
uses.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
