Please refer for veritimus submission -  https://l10n.gnome.org/vertimus/400/390/62/

Replace hi.po with updated translations.

See merge request GNOME/glib!4195

And drop a load of unused variables.

Fixes commit 5040cf19.

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

These tests are expected to cause a thread to deadlock. That seems to be
fine with glibc on Linux, but the glibc version on FreeBSD can detect
the deadlock, and aborts the whole test process with:
```
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Resource deadlock avoided.  Aborting.
```

This is fair enough.

To avoid this causing the test suite to fail, run those two tests in
subprocesses. This also means we’re not carrying a deadlocked thread
around for the rest of the test suite.

Improves on commit 62192925.

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

This reverts commit 365411ea.

Since commit 3a07b2ab, issue 2309 has
been fixed, so we should no longer have failures from valgrind here.

tests: Run expected-to-hang cancellable tests in subprocesses

See merge request GNOME/glib!4198

gunixmounts: Fix use of uninitialised variable

See merge request GNOME/glib!4197

issue 3428: fix comment in escape_string

Closes #3428

See merge request GNOME/glib!4200

This enables us to catch access violation errors in CI and
get meaningful stacktraces with gdb.

Helps #3042

See https://docs.gtk.org/glib/running.html#environment-variables

gi-docgen won't find the method on Windows

Update Swedish translation

See merge request GNOME/glib!4208

Update Chinese translation

See merge request GNOME/glib!4207

CI/msys2-mingw32: Set the G_DEBUGGER environment variable

See merge request GNOME/glib!4205

This reverts commit 6c679fb3.

Merge request !2765 has caused a thread safety regression in
`GCancellableSource` disposal. It landed too late in the cycle to fix
with any confidence before the 2.82 release, so the changes are being
reverted for the `glib-2-82` branch and 2.82.0 release.

This commit is not problematic, but is built entirely on top of the
problematic MR, so has to be reverted.

Fixes: #3448
Re-opens: #774, #2309, #2313

This reverts commit 54d9c26b.

Merge request !2765 has caused a thread safety regression in
`GCancellableSource` disposal. It landed too late in the cycle to fix
with any confidence before the 2.82 release, so the changes are being
reverted for the `glib-2-82` branch and 2.82.0 release.

Fixes: #3448
Re-opens: #774, #2309, #2313

This reverts commit 3a07b2ab.

Merge request !2765 has caused a thread safety regression in
`GCancellableSource` disposal. It landed too late in the cycle to fix
with any confidence before the 2.82 release, so the changes are being
reverted for the `glib-2-82` branch and 2.82.0 release.

Fixes: #3448
Re-opens: #774, #2309, #2313

This reverts commit 0a8cb10f.

Merge request !2765 has caused a thread safety regression in
`GCancellableSource` disposal. It landed too late in the cycle to fix
with any confidence before the 2.82 release, so the changes are being
reverted for the `glib-2-82` branch and 2.82.0 release.

Fixes: #3448
Re-opens: #774, #2309, #2313

Revert !2765 “GCancellable: Use per-instance mutex logic instead of global critical sections” for glib-2-82

See merge request GNOME/glib!4211

Because `epoll_create1()` is what the code in `giounix-private.c`
actually uses.

Spotted by Xuntao Chi.

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

Fixes: #3450

This kind of deeply nested menu is definitely no longer good UI practice
for most apps (deeply nested menus make things hard to find, and require
good mouse control to navigate). However, it does serve as a good
demonstration of the concepts in `GMenuModel`, so keep it, with a
sentence to acknowledge that it’s not a good UI.

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

Fixes: #3451

It was renamed from `macros.txt` a while ago.

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

As per https://gitlab.gnome.org/GNOME/glib/-/issues/3421#note_2206315

:

It seems like there’s agreement that glib_debug should be enabled for
developers and disabled for distros; and it also seems like there’s no
reliable way to figure this out magically (because not everyone ties
things to `-Dbuildtype=*`). So, we’re left with forcing some group of
people to manually set the value of `glib_debug`. There are more
developers/contributors than there are distros, and distros are more
likely to notice an accidentally-slow GLib package than developers are
likely to notice an accidentally-not-asserting-hard-enough local build,
so let’s say:

The default should be `-Dglib_debug=enabled`, and distros should probably
all override that to `-Dglib_debug=disabled`.

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

Fixes: #3421

The changes made in commit bc59e28b
(issue #3399) fixed introspection of the GThread API. However, they
introduced a trampoline in every threading function. So with those
changes applied, the disassembly of `g_mutex_lock()` (for example) was:
```
0x7ffff7f038b0 <g_mutex_lock>    jmp 0x7ffff7f2f440 <g_mutex_lock_impl>
0x7ffff7f038b5                   data16 cs nopw 0x0(%rax,%rax,1)
```

i.e. It jumps straight to the `_impl` function, even with an optimised
build. Since `g_mutex_lock()` (and various other GThread functions) are
frequently run hot paths, this additional `jmp` to a function which has
ended up in a different code page is a slowdown which we’d rather avoid.

So, this commit reworks things to define all the `_impl` functions as
`G_ALWAYS_INLINE static inline` (which typically expands to
`__attribute__((__always_inline__)) static inline`), and to move them
into the same compilation unit as `gthread.c` so that they can be
inlined without the need for link-time optimisation to be enabled.

It makes the code a little less readable, but not much worse than what
commit bc59e28b already did. And perhaps
the addition of the `inline` decorations to all the `_impl` functions
will make it a bit clearer what their intended purpose is
(platform-specific implementations).

After applying this commit, the disassembly of `g_mutex_lock()`
successfully contains the inlining for me:
```
=> 0x00007ffff7f03d80 <+0>:	xor    %eax,%eax
   0x00007ffff7f03d82 <+2>:	mov    $0x1,%edx
   0x00007ffff7f03d87 <+7>:	lock cmpxchg %edx,(%rdi)
   0x00007ffff7f03d8b <+11>:	jne    0x7ffff7f03d8e <g_mutex_lock+14>
   0x00007ffff7f03d8d <+13>:	ret
   0x00007ffff7f03d8e <+14>:	jmp    0x7ffff7f03610 <g_mutex_lock_slowpath>
```

I considered making a similar change to the other APIs touched in #3399
(GContentType, GAppInfo, GSpawn), but they are all much less performance
critical, so it’s probably not worth making their code more complex for
that sake.

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

Fixes: #3417

Backport !4214 “gthread: Move thread _impl functions to static inlines for speed” to glib-2-82

See merge request GNOME/glib!4215

Various small backports to glib-2-82

See merge request GNOME/glib!4213

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