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.
Cast checks are slow. We seem to have some rough consensus that they are
important for debug builds, but not for release builds. Problem is, very
few apps define G_DISABLE_CAST_CHECKS for release builds. Worse, it's
undocumented, so there's no way apps could even be expected to know
about it.
We can get the right default is almost all situations by making this
depend on the __OPTIMIZE__ preprocessor definition. This is a GCC-specific
thing, although Clang supports it too. If the compiler does not define
__OPTIMIZE__, then this commit does no harm: you can still use
G_DISABLE_CAST_CHECKS as before. When checking __OPTIMIZE__, we are
supposed to ensure our code has the same behavior as it would if we do
not, which will be true except in case the check fails (which is
programmer error).
Downside: this will not automatically do the right thing with -Og,
because __OPTIMIZE__ is always defined to 1. We don't want to disable
cast checks automatically if using -O0 or -Og. There's no way to
automatically fix this, but we can create an escape hatch by allowing
you to define G_DISABLE_CAST_CHECKS=0 to force-enable cast checks. In
practice, I don't think this matters much because -Og kinda failed:
GCC's man page says it should be a superior debugging experience to -O0,
but it optimizes variables away so it's definitely not.
Another downside: this is bad if you really *do* want cast checks in
release builds. The same solution applies: define
G_DISABLE_CAST_CHECKS=0 and you'll get your cast checks.
The prefix for GMarkupParseFlags enumeration members is G_MARKUP; this
means that G_MARKUP_PARSE_FLAGS_NONE gets split into
GLib.MarkupParseFlags.PARSE_FLAGS_NONE by the introspection scanner.
The `/*< nick=none >*/` trigraph attribute is a glib-mkenum thing, and
does not affect the introspection scanner; it would also only affect the
GEnumValue nickname, which is not used by language bindings to resolve
the name of the enumeration member. Plus, GMarkupParseFlags does not
have a corresponding GType anyway.
ginsttest-runner defaults to timing out each test after 5 minutes,
but gobject/tests/performance/performance.c defaults to running each
of 18 tests for 15 seconds. The result is close enough to 5 minutes
that the setup overhead is enough to make it time out.
We're only running these tests to prove that they still work, not to
get meaningful performance numbers, so cut them down to 1 second per
test-case (the result of which is that performance.c takes about a
minute).
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't need a cpp toolchain for building glib so lets just
automatically disable tests requiring one when not available.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
In g_signal_parse_name we were looking up for the signal from the name
keeping the mutex locked, but we then retrieved and checked the node
data without keeping the lock, so with another thread potentially
changing that.
We used to perform unneeded lock/unlock dances to perform block, unblock
and disconnect actions, and these were potentially unsafe because we
might have looped in data that could be potentially be changed by other
threads.
We could have also done the same by saving the handlers ids in a
temporary array and eventually remove them, but I don't see a reason for
that since we can just keep all locked without the risk of creating
deadlocks.
Coverity CID: #1474757, #1474771, #1474429
We're calling g_object_notify so let's not make gobject to call it for
us.
This also allows to test that changing a property again doesn't lead to
dispatch properties being called.
This tests that we call a custom dispatch_properties_changed,
even in the absence of connected notify handlers. (A recent
optimization broke that and caused a regression in GTK).
When I optimized GObject to skip property notification
in some cases, I looked for whether the class has a
custom notify vfunc. I overlooked that that
dispatch_properties_changed can also be customized,
and if it is, we better not skip change notification.
This showed up as breakage in the adjustment tests
in the GTK testsuite.
