These have all been documented as deprecated for a long time, but we’ve
never had a way to programmatically mark them as deprecated. Do that
now.
This is based on the list of deprecations from the reverted commit
80fcb1bc2.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #638
This is a new function along the same lines as g_test_bug(): to allow
developers to annotate unit tests with information about the test (what
it tests, how it tests it) for future developers to read and learn from.
It will also output this summary as a comment in the test’s TAP output,
which might clarify test results.
Includes a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1450
This reverts commit 80fcb1bc26.
G_DISABLE_DEPRECATED should never be used by anybody, least of all by
GLib. We have deprecation annotations for the compiler, these days, and
they are much better suited than a macro that makes symbols appear and
disappear. The fact that gtk-doc doesn't understand the deprecation
annotations is a limitation of gtk-doc, and it's gtk-doc that ought to be
fixed.
Commit 80fcb1bc broke GStreamer, which disables old API that was
deprecated before the introduction of the deprecation annotations, but
still uses newly deprecated one, and relies on the deprecation
annotations to do their thing. It also broke libsoup, as it uses
GValueArray in its own API.
It would be nice if docs.c eventually went away — it’s more maintainable
for documentation comments to be next to the definition of the symbols
they document.
Move a few from docs.c, based on what I’ve been modifying recently.
The documentation comments are unchanged apart from fixing an argument
name for G_ALIGNOF.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
As pointed out by gtk-doc, these are all symbols which have been marked
as deprecated, but which aren’t protected by a deprecation guard. We
can’t use G_DEPRECATED_IN_* for them, as they are all non-function
symbols. Instead, wrap them in #ifndef G_DISABLE_DEPRECATED.
In some cases, we also need to wrap one or two functions which use the
deprecated types in G_DISABLE_DEPRECATED too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Both GCC and Clang treat this as a hint that the code won’t be reached,
which helps in the cases where they might not have automatically
detected it already.
It doesn’t change any behaviour of the compiled code, other than
allowing the compiler to go off into undefined behaviour.
See
https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005funreachable.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In C++ we can use nullptr to ensure g_assert_[non]null() is only called
with pointers. This will introduce build failures in tests that would
have previously compiled, but only in C++, and only for code that
misused these macros. Code using the macros properly will be fine.
This change caught a couple bugs in WebKit's API tests, where I had
accidentally used these functions improperly. E.g. this is now a build
failure in C++:
g_assert_null(webkit_context_menu_get_n_items(menu)); /* Oops! */
Either I wanted to use cmpuint there, or I wanted to use
webkit_context_menu_get_items() to receive a GList* instead.
Another example that will no longer build in C++:
g_assert_null(0); /* Contrived, but 0 is not a pointer! */
Add a new G_TEST_OPTIONS_ISOLATE_XDG_DIRS option for g_test_init() which
automatically creates a temporary set of XDG directories, and a
temporary home directory, and overrides the g_get_user_data_dir() (etc.)
functions for the duration of the unit test with the temporary values.
This is intended to better isolate unit tests from the user’s actual
data and home directory. It works with g_test_subprocess(), but does not
work with subprocesses spawned manually by the test — each unit test’s
code will need to be amended to correctly set the XDG_* environment
variables in the environment of any spawned subprocess.
“Why not solve that by setting the XDG environment variables for the
whole unit test process tree?” I hear you say. Setting environment
variables is not thread safe and they would need to be re-set for each
unit test, once worker threads have potentially been spawned.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
Seems a bit odd to have the documentation comment miles from what it’s
actually documenting.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
This is along the same lines as g_assert_cmpstr(), but for variants.
Based on a patch by Guillaume Desmottes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1191
If G_DISABLE_ASSERT is defined, g_assert() is a no-op. Despite it now
being standard practice to *not* use g_assert() in unit tests (use
g_assert_*() instead), a lot of existing unit tests still use it.
Compiling those tests with G_DISABLE_ASSERT would make them silently
no-ops. Avoid that by warning the user loudly.
Note that it’s pretty rare for people to compile with G_DISABLE_ASSERT,
so it’s not expected that this will be hit often.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/976
Using g_assert_cmpfloat() with a float or double causes warnings on the
newest Clang version, because the macro internally promotes all values to
a long double, which Clang warns about. Casting explicitly removes the
warning.
Closes: #1377
Add a test macro that allows comparing two floating point values for
equality within a certain tolerance.
This macro has been independently reimplemented by various projects:
* Clutter
* Graphene
* colord
https://gitlab.gnome.org/GNOME/glib/issues/914
This is happening since f591366eee, that
changed the way tests were skipped to use g_test_skip() instead of just
ignoring them. They are now reported to the log with G_TEST_RUN_SKIPPED
as result.
https://bugzilla.gnome.org/show_bug.cgi?id=790934
This avoids warnings when compiling with -Wconversion on 32-bit
architectures, as the conversion to (long double) is not necessarily
lossless. We don’t care about that, though, since the actual comparison
was done with the correct types, and g_assertion_message_cmpnum() is
only used to print failure information.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788385
All glib/*.{c,h} files have been processed, as well as gtester-report.
12 of those files are not licensed under LGPL:
gbsearcharray.h
gconstructor.h
glibintl.h
gmirroringtable.h
gscripttable.h
gtranslit-data.h
gunibreak.h
gunichartables.h
gunicomp.h
gunidecomp.h
valgrind.h
win_iconv.c
Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.
Sub-directories inside glib/:
deprecated/: processed in a previous commit
glib-mirroring-tab/: already LGPLv2.1+
gnulib/: not modified, the code is copied from gnulib
libcharset/: a copy
pcre/: a copy
tests/: processed in a previous commit
https://bugzilla.gnome.org/show_bug.cgi?id=776504
glibc string.h declares memcpy() with attribute(nonnull(1,2)), causing
calls with NULL arguments to be treated as undefined behaviour.
This is consistent with ISO C99 and C11, which state that passing 0
to string functions as an array length does not remove the requirement
that the pointer to the array is a valid pointer.
gcc -fsanitize=undefined catches this while running OSTree's test suite.
Similarly, running the GLib test suite reports similar issues for
qsort(), memmove(), memcmp().
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
Some testutils external symbols are marked semi-internals, other
internals. It is not obvious what guarantees these symbols provide.
However, tests are now installable, and require the ABI stability
that glib provides for the rest of the symbols.
In my case, I would like to introduce g_assert* compat code for older
glib versions, and be able to use the so-called "internal" ABI.
I propose this change to the headers comments to explain the stability
guarantees. Removing the "internal" = you must not use this, in favor
of semi-internal = this is not documented.
https://bugzilla.gnome.org/show_bug.cgi?id=756077
g_assert_true(), g_assert_false(), g_assert_null(), and
g_assert_nonnull() simply printed out the expression they were
checking, without any further explanation of what went wrong. (In
particular, "g_assert_true(x)" and "g_assert_false(x)" would both
print the same thing on failure.) Add a little bit more context.
https://bugzilla.gnome.org/show_bug.cgi?id=724385
Declare that the previously-unused "..." argument to g_test_init() is
actually a NULL-terminated list of strings indicating testing options,
and add an option "no_g_set_prgname", which keeps g_test_init() from
calling g_set_prgname(). Then we can port glib/tests/option-argv0 to
use gtester, by passing that option.
https://bugzilla.gnome.org/show_bug.cgi?id=711796
When using test harnesses other than gtester (e.g. using TAP),
it can be suboptimal to have the very first failed assertion
abort the test suite.
This commit adds a g_test_set_nonfatal_assertions() that can
be called in a test binary to change the behaviour of most
assert macros to just call g_test_fail() and continue. We
don't change the behavior of g_assert() and g_assert_not_reached(),
since these to assertion macros are older than GTest, are
widely used outside of testsuites, and will cause compiler
warnings if they loose their noreturn annotation.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
These are just like g_assert(), but using a different entry
point for the message, so we can repurpose them together
with the other assertion macros.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
These two assertion macros are commonly used outside tests,
so we can't repurpose them, as we are going to do with the
other assertion macros in the following commits. This
change is in preparation for that.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
Since this feature is so utterly automake-centric, we may as well be
using the same terminology as automake itself (ie: although it's
BUILT_SOURCES, it's DIST_EXTRA, not DISTED).
Also add some comments to the enum explaining that these terms are
really corresponding directly to the automake terms.
https://bugzilla.gnome.org/show_bug.cgi?id=549783
Add a pair of functions for returning strings that don't need to be
freed. This is a bit of a hack but it will turn the 99% case of using
these functions from:
gchar *tmp;
tmp = g_test_build_filename (...);
fd = open (tmp, ...);
g_free (tmp);
to:
fd = open (g_test_get_filename (...), ...);
which is a pretty substantial win.
https://bugzilla.gnome.org/show_bug.cgi?id=549783
g_test_trap_fork() doesn't work on Windows and is potentially flaky on
unix anyway given the fork-but-don't-exec. Replace it with
g_test_trap_subprocess(), which re-spawns the same program with
arguments telling it to run a specific (otherwise-ignored) test case.
Make the existing g_test_trap_fork() unit tests be unix-only (they
never passed on Windows anyway), and add a parallel set of
g_test_trap_subprocess() tests.
Also fix the logic of gtestutils's "-p" argument (which is used by the
subprocess tests); previously if you had tests "/foo/bar" and
"/foo/bar/baz", and ran the test program with "-p /foo/bar/baz", it
would run "/foo/bar" too. Fix that and add tests.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).
If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
g_test_trap_fork() doesn't work on Windows and is potentially flaky on
unix anyway given the fork-but-don't-exec. Replace it with
g_test_trap_subprocess(), which re-spawns the same program with
arguments telling it to run a specific (otherwise-ignored) test case.
Make the existing g_test_trap_fork() unit tests be unix-only (they
never passed on Windows anyway), and add a parallel set of
g_test_trap_subprocess() tests.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
When running a test program (ie, if g_test_init() has been called),
don't pop up a dialog box when a fatal error occurs. Just print the
message to stderr and exit.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
