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.
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.
Add tests in which `g_object_run_dispose()` is called on the source or target
of a `GBinding`. After commit a4fa456e67,
the target test caused a failed assertion in `g_weak_ref_set()` that was not
found by the existing tests. Commit 94ba14d542
weakens the assertion to allow the test to succeed.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2676
When weak references are being cleaned up, it is possible for the `qdata` for
both `quark_weak_locations` and `quark_weak_refs` to have been deallocated,
so that `g_datalist_id_get_data()` returns `NULL` for both. This happens
when `g_object_run_dispose()` is called for the target of a `GBinding`,
and is not an error.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2676
We should mention glib-mkenums in the documentation for
G_DEFINE_ENUM_TYPE and G_DEFINE_FLAGS_TYPE.
We should also mention the macros in the documentation for glib-mkenums.
This way, developers can choose the most appropriate tool for their use
case.
While you might want to use automated tools like glib-mkenums to
generate enumeration types for your library, it's often not entirely
necessary to complicate your build system in order to handle a couple of
enumerations with few values.
Just like we have G_DEFINE macros for object, interface, pointer, and
boxed types, we should provide macros for defining enum and flags types.
We can use pointer exchange now to avoid doing two operations to switch
to the new data pointer.
Since we're asserting in case of invalid data, we can just do this check
at later point, without involving any different behavior.
This changes in the unlikely case that G_DISABLE_ASSERT is defined, as in such
case we should undo the operation.
This makes calls to g_signal_connect_data() and g_signal_connect_object()
with default flags more self-documenting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes code that sets no flags a bit more self-documenting:
using G_TYPE_FLAG_NONE makes it clearer that no special behaviour is
required than literal 0, and clearer that there is no weird casting
between types than (GTypeFlags) 0.
GTypeFlags and GTypeFundamentalFlags occupy the same namespace and the
same bitfield, so I intentionally haven't added
G_TYPE_FUNDAMENTAL_FLAGS_NONE.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As with commit 0932f71460, which did this for refs/unrefs of the
object in `g_object_notify()`, we need to do a similar thing for
refs/unrefs of the instance with `g_signal_emit()`, for all the same
reasons.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Pass arguments to them so that they take minimal time. This will not
produce useful performance profiling results, but will smoketest that
the tests still run, don’t crash, and therefore probably aren’t
bitrotting too badly.
This is useful because a fair amount of work has gone into these
performance tests, and they’re useful every few years to analyse and
compare GObject performance. We don’t want them to bitrot between uses.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When running the test with `-s 0` it would previously crash. Fix that,
and make it so that it only does a single test run in that case.
This will be useful in an upcoming commit for smoketesting the test to
avoid bitrot.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is a partial revert of commit fa8c7c0da using the approach
suggested (and tested) by Kjell Ahlstedt.
It is intended to be temporary pending a proper dig into what’s causing
the regression, just so we can get the 2.73.1 release out.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2672
Coverity notices the `g_object_unref()` call in `g_object_notify()`, but
not the paired `g_object_ref()` call. It therefore incorrectly assumes
that every call to `g_object_notify()` frees the object. This causes a
lot (hundreds) of false positive reports about double-frees or
use-after-frees.
I can’t find a way to fix this using a model file, so the other options
are:
* Manually mark every report as a false positive and keep updating them
as the code changes over time. This would take a lot of maintainer
effort.
* Comment out the `g_object_ref()`/`g_object_unref()` calls when
running static analysis (but not in a normal production build). This
is ugly, but cheap and shouldn’t impact maintainability much.
So this commit implements option 2.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This prevents `-Wunused-function` warnings on platforms which don’t have
`HAVE_OPTIONAL_FLAGS` defined.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
g_object_new_with_custom_constructor needs to handle
freezing notifications in the same way as
g_object_new_internal.
Fixing a bug pointed out by Christian Hergert.
The corner-case we are handling here is that
we don't freeze the notify queue in g_object_init
(because there's no custom ->notify vfunc, but
then we gain a notify handler during instance
init, and instance init also triggers a
notification. Handle this by jit freezing
notification in g_object_notify_by_spec_internal.
Note that this is bad code - instance init really
shouldn't be doing things like this.
Testcase included.
Fixes: #2665
We need to match the conditions in g_object_init
for when we already have a freeze. Without that,
we underflow the freeze count and trigger a
warning.
Fixes: #2666
Beef up the singleton testcase to reproduce a
freeze count underflow when setting properties
at construction time, with a custom constructor.
Helps: #2666
These are deprecated, but it’s easy enough to test them anyway. This
bumps up code coverage a bit and hopefully ensures we don’t accidentally
regress on them in future.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
At the moment these tests basically just ensure that the program’s
compiled properly and doesn’t crash on startup. They don’t check
functionality very deeply.
But they’re a start.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This has been documented in `man gobject-query` for a long time, but
seemingly never implemented.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This makes the output a lot nicer to read:
```
│
├void
│
├GInterface
│ │
│ └GTypePlugin
│
├gchar
⋮
```
rather than
```
|
`void
|
`GInterface
|
`GTypePlugin
|
`gchar
⋮
```
It includes a change to correctly use vertical tees at the top level by
correctly setting the sibling node rather than always setting it to
zero.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This doesn’t change the tests’ behaviour, but moves them to a slightly
more logical location.
They are still not installed or run by default.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1434
Install the properties with a mixture of
g_object_class_install_properties and
g_object_class_install_properties, and verify
that finding them still works, regardless of
whether we use string literals or not.
When the param specs are provided as an array
with g_object_class_install_properties, keep
a copy of that array around and use it for
looking up properties without the param spec
pool.
Note that this is an opportunistic optimization -
currently, it only works for properties of the
class itself, not for parent classes, and it
only works if the property names are identical
string literals (we're at the mercy of the linker
for that).
If we don't get lucky, we fall back to using
the pspec pool as usual.
This may fix Coverity assuming that pspecs are leaked, which is causing
tens and tens of false positives in the latest Coverity reports for
GLib.
Ensure that the pspecs are sunk (if floating) even if adding them to the
class fails (due to validation failure or an identically named property
already existing).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This reverts commit 0ddea2d8e2.
The commit was based on the misunderstanding that types
declared with G_DECLARE_FINAL_TYPE are actually non-derivable.
But that is only the case for types defined with
G_DEFINE_FINAL_TYPE.
Fixes: #2661
If we have no nontrivial notify vfunc, and no signal
handlers for notify, we don't need to maintain the
notify queue. No need to notify if nobody's listening.
Check whether an object has a nontrivial notify vfunc
and avoid creating and updating the notify queue if
it doesn't. We know that there can be no notify signal
handlers at this point. No need to notify if nobody's
listening.
We currently keep a flag for whether an object has
ever had any signal handlers. But even if it had signal
handlers, it may not have any notify handlers. Keep that
information separately, so we can speed up property setting.
According to the commit that introduced these
calls (4b334ef8f1), we are checking
the refcount here to avoid calling g_object_ref
when the refcount is 0, in the rare case that
notification would be triggered during finalize.
But we are now freezing notifications during
finalize, and after recent changes, we no longer call
g_object_ref for notification while a freeze is
in place.
We only need to take a ref on the object when
we call out to external code (ie around
->dispatch_properties_changed). If we avoid
the signal emission, we can avoid the ref/unref
too. This is not currently happening, but
might in the future.
A small reorg that reduces the code and matches
what we do for object_get_property.
Note that as a consequence of this change, we now
check the deprecated flag on the redirected property,
not on the original when setting properties. This
matches what we were already doing for getting
properties.
The code that emits property deprecation warnings
rarely runs, and doesn't need to be inlined
everywhere. It is enough to inline the check for
the deprecation flag.
It is safe not to copy arguments here,
because we are not emitting any signals
before we are done setting the values
as properties.
This matches what we do for g_object_new now.
