Commit Graph

25508 Commits

Author SHA1 Message Date
Philip Withnall
8d613ee7ff tests: Remove unused inline functions from slice tests
These were causing compiler warnings when compiling with clang.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-07 18:26:55 +01:00
Philip Withnall
385ad59f41 Revert "ci: Temporarily disable macOS CI runner until it’s fixed"
This reverts commit e3673202e2.

As per
https://gitlab.gnome.org/Infrastructure/GitLab/-/issues/558#note_1465542,
the macOS CI runner is now back online.
2022-06-07 18:26:55 +01:00
Philip Withnall
dccc1ceebc build: Add native argument to add_languages() for objc
This fixes the macOS build with Meson 0.54 or later.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-07 18:26:55 +01:00
Matthias Clasen
df43536a68 Consistently use param_spec_follow_override 2022-06-07 12:39:58 -04:00
Matthias Clasen
47c12389a0 gobject: Speed up property lookup
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.
2022-06-07 12:39:58 -04:00
Philip Withnall
d7c3b0fbf2 Merge branch 'gatomic-exchange' into 'main'
gatomic: Add APIs to perform atomic int / pointer exchanges

See merge request GNOME/glib!2726
2022-06-07 15:30:34 +00:00
Marco Trevisan (Treviño)
fa4e34667c gatomic: Add APIs to perform atomic int / pointer exchanges
Atomic APIs provide a way to exchange values only if we compare a value
that is equal to the old value, but not to just exchange the value
returning the old one.

However, compilers provide such built-in functions, so we can use them
to expose such functionality to GLib.

The only drawback is that when using an old version of gcc not providing
atomic APIs to swap values, we need to re-implement it with an
implementation that may not be fully atomic, but that is safe enough.

However this codepath should really not be used currently as gcc
introduced __atomic_exchange_n() at version 4.7.4, so 8 years ago.
2022-06-07 17:10:57 +02:00
Philip Withnall
a6f208af8e Merge branch 'array-copy-null-terminated' into 'main'
garray: Fix NULL-termination of GPtrArray copies

See merge request GNOME/glib!2730
2022-06-07 13:47:42 +00:00
Philip Withnall
12dc714437 Merge branch 'gobject-speedup11' into 'main'
Keep a separate flag for notify handlers

See merge request GNOME/glib!2725
2022-06-07 13:43:50 +00:00
Philip Withnall
d0b0f8f90e garray: Rename an internal helper to make its behaviour clearer
`ptr_array_null_terminate()` only `NULL`-terminates the array if its
`null_terminated` flag is set; otherwise it’s a no-op.

Rename the function to `ptr_array_maybe_null_terminate()` to make that a
bit clearer, and make it consistent with `g_ptr_array_maybe_expand()`.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-07 13:31:52 +01:00
Philip Withnall
18a7b19a99 Merge branch 'revert-final-type-check' into 'main'
Revert "gtype: Speed up type checks for final types"

Closes #2661

See merge request GNOME/glib!2727
2022-06-07 11:50:58 +00:00
Philip Withnall
3076c60e9c Merge branch 'gobject-speedup10' into 'main'
gobject: Avoid redundant atomics

See merge request GNOME/glib!2724
2022-06-07 11:46:23 +00:00
Philip Withnall
b1e371034d Merge branch 'gobject-speedup8' into 'main'
Avoid g_param_spec_get_redirect_target

See merge request GNOME/glib!2722
2022-06-07 11:45:25 +00:00
Sebastian Dröge
5de59d34e1 Merge branch 'static-analysis-fixes' into 'main'
tests: Various static analysis fixes

See merge request GNOME/glib!2731
2022-06-07 10:50:18 +00:00
Sebastian Dröge
63974faebf Merge branch 'coverity-pspecs' into 'main'
gobject: Sink floating pspecs if adding them to a class fails

See merge request GNOME/glib!2732
2022-06-07 10:49:54 +00:00
Philip Withnall
8f7df344b6 gobject: Sink floating pspecs if adding them to a class fails
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>
2022-06-07 11:20:32 +01:00
Philip Withnall
9926703494 tests: Avoid an uninitialised variable warning in slice-memchunk test
Dynamically, all the right elements of `ps` are initialised before they
are used. However, scan-build doesn’t think so. It (probably) thinks
that `number_of_blocks` could change value between the different loops
over `ps`.

Try and avoid that by marking `number_of_blocks` (and related variables)
as `const`.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-07 11:16:57 +01:00
Philip Withnall
6c0bde8aa4 tests: Fix a scan-build warning about uninitialised threads
It seems that scan-build assumes `n_threads > 0`, but doesn’t assume a
tighter condition than that, and hence assumes that the two loops to
initialise and join the threads have different numbers of iterations.

That’s obviously not the case.

Try and help scan-build out here by marking `n_threads` as `const`. I
don’t know if this will work, but it’s correct regardless.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-07 11:09:39 +01:00
Philip Withnall
504727c317 gvariant: Zero-initialise GVariantBuilder children under static analysis
scan-build can’t link the types used in `g_variant_builder_init()` with
the (same) types used in `g_variant_builder_end()`, so ends up assuming
that the children have not been initialised.

At runtime, this is prevented by the precondition checks on
`GVSB()->offset` in `g_variant_builder_end()`. scan-build doesn’t notice
that though.

Avoid a scan-build warning by zero-initialising the children array when
running static analysis. Doing this unconditionally would be an
unnecessary performance hit.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-07 11:08:14 +01:00
Philip Withnall
423bcab9f4 garray: Change free/unref semantics under static analysis
Recent changes to `GPtrArray` and/or Coverity mean that Coverity is now
assuming that `g_ptr_array_free (my_array, TRUE)` can leak memory. This
is true in the case that `g_ptr_array_ref (my_array)` has been called
elsewhere, but Coverity never actually verifies that.

Very little (or no?) GLib code mixes `g_ptr_array_free()` with
`g_ptr_array_{ref,unref}()`, so this isn’t a problem in practice.

However, it has created a hundred or more false positives in Coverity
(as pointer arrays are widely used within GLib and GIO), which is a
complete pain.

Before taking the dramatic step of ditching Coverity due to its
atrocious false positive rate, let’s try changing the semantics of
`g_ptr_array_free()` only when running under Coverity.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-07 11:05:26 +01:00
Philip Withnall
14f4b38fb1 tests: NULL-initialise some variables to help scan-build
Dynamically, these will only ever be used after they’ve been initialised
due to correct checking of `use_udp` throughout the test. However,
that’s a global variable and the static analyser is assuming it might
change value. So help it out by NULL-initialising the variables so they
can never be used uninitialised.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-07 11:04:25 +01:00
Philip Withnall
c11e64e7ae garray: Fix NULL-termination of GPtrArray copies
The code was accidentally NULL-terminating the source array rather than
the copy.

This fixes commit ee247c0a2d.

Spotted by the `array-test` installed test in
https://gitlab.gnome.org/GNOME/glib/-/jobs/2047993.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-07 09:38:21 +01:00
Philip Withnall
c572d013a4 tests: Use g_assert_*() rather than g_assert() in once
It won’t get compiled out with `G_DISABLE_ASSERT`.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2022-06-07 09:25:30 +01:00
Philip Withnall
5616e1b16e tests: Reduce number of threads in once test under valgrind
Valgrind has a limit of 500 threads (unless you pass `--max-threads` to
it). Running this test with more threads than that under valgrind seems
unnecessary, so reduce the thread limit when valgrind support is
enabled.

This should fix the following test failure:
```
Use --max-threads=INT to specify a larger number of threads
and rerun valgrind

valgrind: the 'impossible' happened:
   Max number of threads is too low

host stacktrace:
==5239==    at 0x580427EA: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239==    by 0x58042917: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239==    by 0x58042B80: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239==    by 0x58042BB0: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239==    by 0x58099C0E: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239==    by 0x580E6839: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239==    by 0x5809D3E9: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239==    by 0x58098DB2: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239==    by 0x5809AE97: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239==    by 0x580E40B0: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable syscall 56 (lwpid 5239)
==5239==    at 0x4AB0315: clone (in /usr/lib64/libc-2.33.so)
client stack range: [0x1FFEFFB000 0x1FFF000FFF] client SP: 0x1FFEFFC468
valgrind stack range: [0x1008BAA000 0x1008CA9FFF] top usage: 8776 of 1048576

Thread 2: status = VgTs_WaitSys syscall 202 (lwpid 5268)
==5239==    at 0x4AAADDD: syscall (in /usr/lib64/libc-2.33.so)
==5239==    by 0x491E2C2: g_mutex_lock_slowpath (gthread-posix.c:1495)
==5239==    by 0x491E37C: g_mutex_lock (gthread-posix.c:1519)
==5239==    by 0x491E489: g_cond_wait (gthread-posix.c:1578)
==5239==    by 0x401436: once_thread_func (once.c:96)
==5239==    by 0x48E9F31: g_thread_proxy (gthread.c:829)
==5239==    by 0x491DE3A: linux_pthread_proxy (gthread-posix.c:1271)
==5239==    by 0x4C002A4: start_thread (in /usr/lib64/libpthread-2.33.so)
==5239==    by 0x4AB0322: clone (in /usr/lib64/libc-2.33.so)
client stack range: [0x5022000 0x5820FFF] client SP: 0x5820D28
valgrind stack range: [0x100B267000 0x100B366FFF] top usage: 3544 of 1048576
```

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #1910
2022-06-07 09:25:24 +01:00
Matthias Clasen
54c867a01e Revert "gtype: Speed up type checks for final types"
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
2022-06-06 16:39:41 -04:00
Matthias Clasen
7d8e2fcf6d Cosmetic coding style fixes 2022-06-06 14:28:31 -04:00
Matthias Clasen
f755f445c6 Avoid property notification during g_object_set
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.
2022-06-06 14:26:58 -04:00
Matthias Clasen
8851112b8d Avoid property notification during object construction
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.
2022-06-06 14:26:45 -04:00
Matthias Clasen
8b328f1d6d Keep a separate flag for notify handlers
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.
2022-06-06 14:25:41 -04:00
Matthias Clasen
16a8b6d819 gobject: Avoid redundant atomics
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.
2022-06-06 14:13:20 -04:00
Matthias Clasen
9d7d439607 Avoid g_param_spec_get_redirect_target
Inline the getting of the redirect target.
This is a rare thing, and the calls were
showing up in profiles.
2022-06-06 14:00:33 -04:00
Philip Withnall
2b437402e8 Merge branch 'gobject-speedup7' into 'main'
Avoid g_object_ref/unref in some cases

See merge request GNOME/glib!2721
2022-06-06 17:53:42 +00:00
Philip Withnall
f8c5d71104 Merge branch 'gobject-speedup9' into 'main'
Avoid g_type_class_peek

See merge request GNOME/glib!2723
2022-06-06 17:16:33 +00:00
Matthias Clasen
e70a4eef77 Avoid g_object_ref/unref in some cases
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.
2022-06-06 12:33:34 -04:00
Matthias Clasen
b185f6e5d0 Merge branch 'gobject-speedup4' into 'main'
Don't inline deprecation warnings

See merge request GNOME/glib!2715
2022-06-06 15:58:09 +00:00
Matthias Clasen
19551ac983 Avoid g_type_class_peek
Most of the time, properties belong to the class
we set them on. Check that first, before going
into GType, which takes locks and whatnot.
2022-06-06 11:51:55 -04:00
Matthias Clasen
a4940943e5 Move deprecation warnings to object_set_property
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.
2022-06-06 11:29:16 -04:00
Matthias Clasen
d97c948567 Don't inline deprecation warnings
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.
2022-06-06 11:29:14 -04:00
Philip Withnall
d730cfcdf4 Merge branch 'gobject-speedup2' into 'main'
Simplify g_object_new_with_properties

See merge request GNOME/glib!2713
2022-06-06 15:18:01 +00:00
Philip Withnall
3ce923711b Merge branch 'drop-collate-files' into 'main'
tests: Drop redundant collate test data files

See merge request GNOME/glib!2692
2022-06-06 14:05:21 +00:00
Philip Withnall
d7ff2b3ad1 Merge branch 'gobject-speedup5' into 'main'
Don't copy values in g_object_new

See merge request GNOME/glib!2716
2022-06-06 13:51:13 +00:00
Philip Withnall
89f4c876ef Merge branch 'roadmap-docs' into 'main'
docs: Add a roadmap policy

See merge request GNOME/glib!2681
2022-06-06 13:07:09 +00:00
Philip Withnall
22fea9d24a Merge branch 'gobject-speedup3' into 'main'
Simplify g_object_notify_by_pspec

See merge request GNOME/glib!2714
2022-06-06 13:02:52 +00:00
Sebastian Dröge
0629081767 Merge branch 'missing-nullable' into 'main'
Add nullable annotation to return value of `g_variant_dict_lookup_value`.

Closes #1941, #2640, #2625, and #2629

See merge request GNOME/glib!2719
2022-06-06 06:56:57 +00:00
Hugo Parente Lima
1b3d5cff0b Add nullable annotation to return value of g_variant_dict_lookup_value. 2022-06-06 09:43:25 +03:00
Zurab Kargareteli
12e19ec73c Update Georgian translation 2022-06-05 17:17:17 +00:00
Matthias Clasen
ec69e7c463 Simplify g_object_new_with_properties
This function was doing an unnecessary extra
copy of the GValues. We can avoid that.
2022-06-03 07:10:08 -04:00
Matthias Clasen
149b0f03b4 Simplify g_object_notify_by_pspec
Fold get_notify_pspec into its only caller.
2022-06-01 19:33:04 -04:00
Matthias Clasen
95caffcd26 Don't copy values during g_object_set
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.
2022-06-01 18:22:10 -04:00
Matthias Clasen
d50bc3c1c3 Don't copy values in g_object_new
We can safely use the values without copying here.
This is safe because we are not emitting any
signals before we are done setting the values
as properties.
2022-06-01 18:20:41 -04:00