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>
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.
These have all been added manually, as I’ve finished all the files which
I can automatically detect.
All the license headers in this commit are for LGPL-2.1-or-later, and
all have been double-checked against the license paragraph in the file
header.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()`), so that they use
`g_memdup2()` instead.
In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
We have a "good" implementation of g_clear_signal_handler() in
form of a macro. Use it, and don't duplicate the code.
Also add a comment to the documentation that "instance" in fact must
not point to a valid GObject instance -- if the handler ID is unset.
Also reword the documentation about the reasoning for why a macro
version exists. The reason is not to use the function "without
pointer cast". I don't think the non-macro version requires any
pointer cast, since "instance" is a void pointer. Was this referring
to the handler_id_ptr? That doesn't seem right either, because the
caller should always provide a "gulong *" pointer and nothing else.
g_signal_new_valist() is called by g_signal_new(), which is probably
the most common way to create a signal.
Also, in almost all cases is the number of signal parameters small.
Let's optimize for that by using a stack allocated buffer if we have
few parameters.
Also adds a test that checks that the G_SIGNAL_RUN flags are handled
correctly and the class signal handler is called at the right times.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/513
This commit only looks at the `Returns:` lines in the documentation, and
has examined all of them in the file. Function arguments have not been
checked.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2227
commit 916297be79 added a hash table
to provide constant time lookups of signal handlers.
Unfortunately, that commit neglected to remove handlers from
g_signal_connect_object calls from the hash table that are
disconnected implicitly when the associated object goes away.
This commit addresses that bug by changing the closure invalidate
handler associated with the signal connection to properly remove the
handler from the hash table.
This was mostly machine generated with the following command:
```
codespell \
--builtin clear,rare,usage \
--skip './po/*' --skip './.git/*' --skip './NEWS*' \
--write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).
Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.
There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.
If I’ve missed anything, please file an issue!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Making this validation code public allows projects to validate a
GParamSpec name before creating it. While hard-coded GParamSpec don't
need this, we can't afford crashing the main program for dynamically
generated GParamSpec from user-created data.
In such case, we will need to validate the param names and return errors
instead of trying to create a GParamSpec with invalid names.
Includes modifications from Philip Withnall and Emmanuele Bassi to
rearrange the new function addition and split it into one function for
GParamSpecs and one for GSignals.
The `G_TYPE_IS_INSTANTIATABLE()` check is redundant with a precondition
on the function.
The `g_type_class_peek()` check seems like a pointless restriction: it
should be possible to check for a signal from a class init function.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #650
The format has never previously been specified. It can be anything, but
for sanity’s sake disallow empty strings.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #358
Rather than adding a canonicalised and non-canonicalised version of the
signal to `g_signal_key_bsa`, just add the canonicalised version. Signal
lookups always use the canonicalised key (since the previous commit).
This saves space in `g_signal_key_bsa`, which should speed up lookups;
and it saves significant space in the global `GQuark` table (a 9.6%
reduction in entries in that table, by a rough test using
gnome-software).
We have to be a little more relaxed on the signal name validation than
we are for property name validation, as GTK installs a
`-gtk-private-changed` signal which violates the signal naming rules.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, we’d look up the signal name as passed to (for example)
`g_signal_lookup()`, and rely on the fact that signals are inserted
twice into `g_signal_key_bsa`; once in canonical form and once not.
In preparation for only inserting signals into `g_signal_key_bsa` once,
we now try looking up a signal with the given signal name and, if that
fails, try canonicalising the name and trying again.
This is a performance hit on lookups for non-canonical names, but
shouldn’t affect the performance of lookups for canonical names. If
people want performance, they should use canonical names.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #358
This eliminates a call from every call site of signal_id_lookup(). It
introduces no functional changes, but allows subsequent refactoring.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Since signal names are the same as property names, reference between the
two. Improve the formatting, and make it clearer that `_` is
discouraged.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #358
This uses a 32bit hole in the GObject structure on 64bit arches
as a flag field which can be optionally used for some preformance hints.
Currently there is a flag that gets set any time you connect to a signal
on a GObject which is used as early bailout for signal emissions, and using
the flags field instead of a user-data for checking if a GObject is
under construction.
If we specify a c_marshaller, g_signal_newv() will never assign an
va_marshaller automatically. So either use NULL (for simple cases), or
specify both to avoid the generic performance penalty.
It allows to disconnect a signal handler from GObject instance and at the same
time to nullify the signal handler.
Provided also a macro for handler type conversion.
It's theoretically possible that we could have a case where this would
actually return NULL, but it's difficult to imagine a valid program that
would contain such a case.
Add an explicit assert here to quiet up static analysis.
See the bug for more discussion.
Coverity CID: 1159477
https://bugzilla.gnome.org/show_bug.cgi?id=730296
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
gtk-doc doesn’t make the return type clear, because these are macros
rather than inline functions, so people often have to guess at the
return type (or look it up from g_signal_connect_closure(), but that’s
hard work).
Make it clear that the return type for handler IDs is gulong. While
there, fix the capitalisation of ‘id’ to ‘ID’ in a few places.
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
This is almost always what you want, because if you're using this you
want to know if any "custom code" (i.e. not the default class closure)
is going to be run if you emit this signal.
I looked at all the existing uses of this and they were all broken in the
presence of g_signal_override_class_closure().
https://bugzilla.gnome.org/show_bug.cgi?id=754986
