If a test is marked with g_test_incomplete(), then it is expected to
fail, so when it fails the test executable should still exit 0
(or possibly 77, if all tests are either skipped or incomplete).
Signed-off-by: Simon McVittie <smcv@collabora.com>
In the test for the unit testing framework, we might as well have
exemplary behaviour. Leave behind a single call to g_assert (TRUE)
just to prove that it still works.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The TAP specification says that failing tests that are currently
expected to fail (like Automake's XFAIL) are to be reported as
"not ok", with that failure ignored as a result of the TODO
directive, with this example:
not ok 3 - infinite loop # TODO halting problem unsolved
A test reported as "ok # TODO" indicates that something that is
expected to fail has unexpectedly succeeded, similar to Automake's
XPASS.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Assigning the gpointer return value from g_atomic_pointer_get() to a
gsize variable was not making -Wbad-function-cast happy. Assign to an
intermediate gpointer variable and then cast that instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1475
7efd76dd67 added these configure time tests to work around a bug
with older Android. Since the test didn't take Windows into account it
wrongfully applied the workaround on Windows too, breaking the build.
With meson this wasn't an issue since the check is skipped on Windows there
and our CI didn't catch this issue.
Change the test to run on Android only for meson and autotools.
This also makes it clear that the test+code can be dropped again if we stop
supporting older Android versions at some point.
g_test_skip() is appropriate for tests that can't run due to missing
functionality on the host system, whereas g_test_incomplete() is
for expected-to-fail tests for unimplemented functionality in the
code under test.
See also https://bugzilla.gnome.org/show_bug.cgi?id=793635 and
commit 5459b345.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Testing that an interned string is released once its last reference is
dropped is not possible without a hook into the interning machinery;
just checking that the returned pointer for the same string is going to
be different after the last release() is not guaranteed to work, as the
systema allocator is perfectly within its rights to recycle pointers, as
long as they are unique while valid.
Closes#1467
Releasing GVolumeMonitor before g_volume_mount finish cause that
g_volume_get_mount returns NULL, because the mount is not correctly
propagated to the volume.
https://gitlab.gnome.org/GNOME/glib/issues/1458
The gresource code uses libelf if available but that also depends on mmap but isn't
guarded with HAVE_MMAP. This can make the build fail under MSYS2 where a mingw version
of libelf exists but there is no mmap.
Instead of guarting the libelf code with HAVE_LIBELF add a new macro named USE_LIBELF
which is only defined if libelf and mmap support are available.
Also install the mingw libelf version for CI so we catch similar errors in the future.
When checking that the timezone code falls back to UTC if a zone is
unknown, don’t use ‘PST’, because that can actually exist on some
systems.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1433
The previous 2.57.2 release failed. The tarball for this one will be
generated using `ninja dist`, but should still be good to be built using
autotools. `make distcheck` on it has been tested.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1436
See previous commit; same reasoning behind the commit, except that these
sources weren’t (yet) causing `make distcheck` to fail.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Instead of messing around with EXTRA_*_SOURCES and manually handling .lo
files, why not just add gwin32.c to the GLib sources conditionally?
This will hopefully fix `make distcheck` failing due to gwin32.Plo not
being generated in the sub-builddir≠srcdir stage, due to depcomp
inexplicably not generating it. (Note that it is correctly generated in
non-distcheck builds.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The parser state machine for bookmark files did not handle unexpected
nesting of elements, such as a <bookmark> element inside a <title>
element — it would print a critical warning rather than returning a
GError.
Fix that, and add various unit tests for it. The set of tests includes
various other general markup tests as provided by Jussi Judin.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1035
That should format these character classes correctly in the
documentation, and prevent them being interpreted by gtk-doc as (broken)
Markdown hyperlinks.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This fixes a gtk-doc complaint about the argument name not matching
what’s used in the gtk-doc comment.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
They should either be generated at build time, or ignored completely,
depending on the presence of --[enable|disable]-man.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It is a bug if we distribute files which are generated at build time —
they should be built on the machine which is compiling GLib, not be
shipped in the tarball.
This brings the autotools-generated tarball in line with the
ninja-generated one, with the exception of man pages and gtk-doc HTML
output.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If something which looks like a closing tag is left unfinished, but
isn’t paired to an opening tag in the document, the error handling code
would do a null pointer dereference. Avoid that, at the cost of
introducing a new translatable error message.
Includes a test case, courtesy of pdknsk.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1461
When formatting the error messages for markup parsing errors, the parser
was unconditionally reading a UTF-8 character from the input buffer —
but the buffer might end with a partial code sequence, resulting in
reading off the end of the buffer by up to three bytes.
Fix this and add a test case, courtesy of pdknsk.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1462
The documentation claims that g_volume_get_mount should succeed after
g_volume_mount. Let's update mounts before releasing g_volume_mount to
be sure that the mount is added to the corresponding volume. The same
is done in GVfsUDisks2VolumeMonitor.
https://gitlab.gnome.org/GNOME/glib/issues/1458
