This makes it easier to debug test failures, by ensuring that g_debug()
and g_test_message() are printed as TAP diagnostics.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1528
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_object_bind_property() (transfer none) returns a GBinding with an existing internal
reference which is active as long as the "binding" is. This allows to optionally use
the binding without any memory management, as it will remove itself when it is no longer
needed.
There are currently three ways to remove the "binding" and as a result the reference:
1) Either the source or target dies and we get notified by a weakref callback
2) The user unrefs the binding until it is destroyed (which is semi-legal,
but worked and is used in the test suite)
3) The user calls g_binding_unbind()
In case (3) the problem was that it always calls unref even if the "binding" is already
gone, leading to crashes when called from bindings multiple times.
In #1373 and !197 it was noticed that a function always unrefs which would be a
"transfer full" annotation, but the problem here is that it should only remove the
ref when removing the "binding" and the annotation should stay "transfer none".
As a side effect of this fix it is now also possible to call g_binding_unbind() multiple
times where every call after the first is a no-op.
This also adds explicit tests for case (1) and (3) - only case (3) is affected by this change.
Part of runMkenumsWithHeader() was duplicated in test_reproducible(),
and would otherwise need to be duplicated again in upcoming tests. Many
places duplicated decoding stdout/stderr and checking the exit code.
Introduce a named tuple for the returned fields; and factor out writing
a template file to pass with --template.
The new python module, added with 0.46, works with Python 2 and 3 and
allows to pass a path for the interpreter to use, if the need arises.
Previously the meson build set PYTHON, used in the shebang line of
the scripts installed by glib, to the full path of the interpreter.
The new meson module doesn't expose that atm, but we should set it to
a executable name anyway, and not a full path.
Several of our tools are installed and are used by other projects to
generate code. However, there is no 'install' when projects use glib
as a subproject.
We need some way for glib to 'provide' these tools so that when some
project uses glib as a subproject, find_program('glib-mkenums') will
transparently return the glib-mkenums we just built.
Starting from Meson 0.46, this can be done with the
`meson.override_find_program()` function.
As a bonus, the Meson GNOME module will also use these
'overriden'/'provided' programs instead of looking for them in PATH.
PEP8 says that:
"Comparisons to singletons like None should always be done with is or
is not, never the equality operators."
glib uses a mix of "== None" and "is None". This patch changes all
cases to the latter.
The implementation is silently discarding this anyway, and
g_object_unref() is using atomic operations. So this should be safe.
Having this here triggers -Wdiscarded-qualifiers when g_clear_pointer()
is fixed to use __typeof__().
The implementation is silently discarding this anyway, and
g_object_unref() is using atomic operations. So this should be safe.
Having this here triggers -Wdiscarded-qualifiers when g_clear_pointer()
is fixed to use __typeof__().
Switch the check which tests whether the object has been finalised from
being a use-after-free, to using a weak pointer which is nullified on
finalisation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If some other per value option was present than 'skip' or 'nick' then
a KeyError would occur. Ignoring such options matches the behaviour of
the old, Perl-based glib-mkenums.
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
https://gitlab.gnome.org/GNOME/glib/issues/1360
This makes them a bit more unique (and, crucially, in the g_* namespace)
to avoid shadowing collisions with calling code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/258
It's been 4 years and 8 development cycles since we introduced
G_ADD_PRIVATE and offset-based private data access. It is now
time to finally deprecate the old mechanism.
Closes: #699
Meson has the ability to classify tests according to "suites", a list of
tags. This is especially useful when we want to run specific sets of
tests — e.g. only GLib's tests — instead of the whole test suite. It
also allows us to classify special tests, like "slow" ones, so that we
can only run them when needed.
In master, it is already possible to build GLib using Visual Studio
using Meson[1] for some time, so we should focus on maintaining only the
Meson build files for building GLib with Visual Studio.
[1]: There are caveats when building with Visual Studio 2008, namely
that one needs to use the mt command to embed the manifests that
are generated with the .exe/DLLs, for all builds, and that in the
case where the compilation hangs on Visual Studio 2008 x64, as a
workaround, should stop the build by terminating all cl.exe tasks
and change the compiler optimization flag from /O2 (full speed) to
/O1 (optimize for size), due to compiler optimization issues.
It's mostly not used anymore and doesn't do what it says it does.
The docs state that it affects GList, GSList, GNode, GMemChunks, GSignal,
GType n_preallocs and GBSearchArray while:
* GList, GSList and GNode use GSlice and are not affected
* GMemChunks is gone
* GType npreallocs is ignored
It also states that it can be used to force the usage of g_malloc/g_free,
which is handled by G_SLICE=always-malloc now.
The only places where it's used is in signal handling through GBSearchArray
and in GValueArray (deprecated). Since it's unlikely that anyone wants to
reduce allocation sizes just for those cases remove the build option.
valgrind.h is a verbatim copy taken from Valgrind project. Previously
that file had local changes that got dropped by last update. To avoid
regressing again, do not edit valgrind.h anymore and instead add a
gvalgrind.h wrapper that gets included instead.
This fix 2 errors:
- uintptr_t is not defined when including valgrind.h on mingw.
- MSVC compiler is not supported on amd64-Win64 platform.
The timer tests expect that a small value for sleep does not result in
no sleep at all. Round up to the next millisecond to bring it more in line
with other platforms.
This fixes the glib/timer tests.
This makes the 'threadtests' time out since that uses small usleeps a lot and
until now didn't wait at all, but now always waits a msec. Reduce the amount
of tests done on Windows to get the runtime down to something reasonable again.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
On non-glibc platforms gettext is provided by extra libintl dependency.
We wrongly thought libintl is an internal dependency and applications
needs to explicitly link on it, but turns out that breaks many
applications and with autotools the .pc generated actually has -lintl in
public "Libs:".
https://bugzilla.gnome.org/show_bug.cgi?id=796085
Do not add support for its subtypes, since all their constructors return
GParamSpec*, and g_param_spec_unref() takes a GParamSpec* rather than a
gpointer — adding G_DEFINE_AUTOPTR_CLEANUP_FUNC() for subtypes of
GParamSpec results in compiler warnings about mismatched parameter
types (GParamSpecBoolean* vs GParamSpec*, for example).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=796139
-z nodelete breaks the libresourceplugin module usage in the resources.c
test, which expects to be able to unload it.
Make the Meson build match what the autotools build does: only pass
glib_link_flags to the headline libraries (glib-2.0, gio-2.0,
gobject-2.0, gthread-2.0, gmodule-2.0) and omit it from all other build
targets.
https://bugzilla.gnome.org/show_bug.cgi?id=788771
The -fstack-protector-strong used in many distributions by default has a
rather drastic slowdown of the fast path in generated _get_type()
functions using G_DEFINE_* macros. The amount can vary by architecture,
GCC version, and compiler flags.
To work around this, and ensure a higher probability that our fast-path
will match what we had previously, we need to break out the slow-path
(registering the type) into a secondary function that is not a candidate
for inlining.
This ensures that the common case (type registered, return the GType id)
is the hot path and handled in the prologue of the generated assembly even
when -fstack-protector-strong is enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=795180
