In principle we could script this so that each max-version.c is compiled
26 times, once per possible MAX_VERSION, but I haven't implemented
that here: just pinning to the oldest possible version is sufficient to
reproduce #2796.
These aren't included in the installed-tests, since they don't really
do anything at runtime (the important thing is that they compile
without warnings).
Reproduces: #2796
Signed-off-by: Simon McVittie <smcv@collabora.com>
The function adjusting private struct size to private struct offset
should be `g_type_class_adjust_private_offset`, instead of the
previously misspelled `g_type_class_add_instance_private` in comment.
Fixes#2791
When collecting varargs, ignore the NOCOPY_CONTENTS
flag for variants. That is what our docs advice for
refcounted types, and it fixes a regression that
was inadvertendly introduced when we stopped doing
some extra GValue copies.
Includes a test case by Philip Withnall.
Fixes: #2774
They only indicate whether the value had to be modified to keep it
valid. That doesn’t matter when binding values.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1498116, #1498114
The usual use of G_DISABLE_CAST_CHECKS is to define it without giving it
a value. The value was never looked at until
f946e45a0c, where I decided it would be
cool to ignore it if defined to 0. But this broke the original usage, so
we need to revert that.
I thought it would be a good idea to look at the value in order to give
applications an off switch for the new behavior, so you could continue
to build optimized builds with cast checks enabled. We could still try
to find a way to do that in the future if desired, e.g. by introducing a
new G_ENABLE_CAST_CHECKS definition. But this doesn't seem especially
important. G_DISABLE_CAST_CHECKS is not documented anyway, so how we
handle cast checks is entirely up to GLib.
For unclear reasons, universal_newlines=True doesn't seem to set the
text encoding correctly. Even if I set only encoding='utf-8', the test
fails. The combination here works for me, \o/.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
There is currently no `dllimport` attribute on any of our function,
which prevents MSVC to optimize function calls.
To fix that issue, we need to redeclare all our visibility macros for
each of our libraries, because when compiling e.g. GIO code, we need
dllimport in GLIB headers and dllexport in GIO headers. That means they
cannot use the same GLIB_AVAILABLE_* macro.
Since that's a lot of boilerplate to copy/paste after each version bump,
this MR generate all those macros using a python script.
Also simplify the meson side by using `gnu_symbol_visibility : 'hidden'`
keyword argument instead of passing the cflag manually.
This leaves only API index to add manually into glib-docs.xml when
bumping GLib version. That file cannot be generated because Meson does
not allow passing a buit file to gnome.gtkdoc()'s main_xml kwarg
unfortunately.
Instead of replacing the slice allocator wholesale, we can start phasing
it out by having GTypeInstance use the system allocator on operating
systems where we can assume good performance profiles.
We cannot commit to fully gutting GSlice in the cases where we might
still need it, like the G(S)List allocator and small, similarly-sized
data structures.
The main user of GSlice is still GTypeInstance/GObject, and those have
moved out of the sweet spot of GSlice's performance envelove over the
years, with larger instance sizes and private data.
See: #1079
The validate() vfunc for GParamSpecParam returns FALSE for empty GValue,
which means the is_valid() vfunc should do the same.
This avoids a segfault when calling g_param_value_is_valid() on a
GParamSpecParam.
Fixes: #2770
This goes undiagnosed under normal circumstances, but is a critical
warning (which is fatal by default) under G_ENABLE_DIAGNOSTIC. This is a
programming error, so we should only exercise it under
g_test_undefined(), and only in a test that is intentionally doing this
(as in the previous commit).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This was previously exercised (probably by mistake) in
gobject/tests/type.c, but without making any assertions about what
happened, and the test would fail under G_ENABLE_DIAGNOSTIC if GLib was
compiled with debug enabled.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If a deprecated property only gets set because it is G_PARAM_CONSTRUCT
or G_PARAM_CONSTRUCT_ONLY, then there is nothing for the library user
to fix, and we should not emit a deprecation warning.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2748
Signed-off-by: Simon McVittie <smcv@collabora.com>
- Insert missing word "from".
- Remove space between function name and "()" so syntax highlighting
can recognise it as a function.
- Avoid "you"/"your" when discussing the reentrancy issues of regular
UNIX signal handlers, because it gives the false impression that
these issues are applicable to g_unix_signal_source_new().
Unrelated:
- Fix missing space in documentation of g_signal_new_class_handler().
We've various macros definitions that are depending using C++ features
that may not work in all the standard versions, so recompile the cxx
tests that we have in all the ones we want to support.
If a deprecated property only gets set because it is G_PARAM_CONSTRUCT
or G_PARAM_CONSTRUCT_ONLY, then there is nothing for the library user
to fix, and we should not emit a deprecation warning.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2748
Signed-off-by: Simon McVittie <smcv@collabora.com>
Those tools are not needed at runtime for typical applications,
distributions typically package them separately.
This makes `meson install --tag runtime` skip installation of those
tools. Omitting `--tag` argument will still install them, as well as
with `--tag bin,bin-devel`.
See https://mesonbuild.com/Installing.html#installation-tags.
GCC isn't smart enough to recognise that the assertion on the size of
N_PROPERTIES also affects the assertion on the GParamSpec array access,
so we need to coalesce the two checks into one to avoid an array-bounds
compiler warning.
GParamSpec nicks and blurbs are effectively a deprecated feature,
or at least unused by most libraries these days. Since a number
of C libraries (i.e. GTK4) have started to null these out, annotate
them as `(nullable)` so bindings can do the same.
Closes#2719
All of these warnings indicate programmer error, so critical is most
appropriate here.
Exceptions: deprecation warnings are just warnings. Also, warnings that
are worded with uncertainty can remain warnings rather than criticals.
