The GMemoryMonitor interface uses G_DECLARE_INTERFACE, which provides a
typedef for the interface dummy type. We declare the same type inside
the global giotypes.h header, which leads to typedef redeclaration
warnings on toolchains that do not support—intentionally or not—the C11
feature of typedef redefinition.
While we do have a toolchain requirement for C11 typedef redefinitions
listed on our wiki, we also suspended it temporarily to allow users of
non-C11 compilers to work on newer versions of GLib; so, let's keep them
working a while longer.
Python tuple comparisons actually do what we want for comparing major
and minor versions, so tidy things up by using that.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Even if the key already exists in the table, `g_hash_table_add()` will
call the hash table’s key free func on the old key and will then replace
the old key with the newly-passed-in key. So `key` is always `(transfer
full)`.
In particular, `key` should never need to be freed by the caller if
`g_hash_table_add()` returns `FALSE`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This reverts commit b6d8efbebc.
This GLib API is good, but the implentation is not ready, so there's no
reason to commit to the API in GLib 2.64. We can reland again when the
implementation is ready.
There are three problems: (a) The glib-networking implementation normally
works, but the test has been broken for a long time. I'm not comfortable
with adding a major new feature without a working test. This is
glib-networking#104. (b) The WebKit implementation never landed. There
is a working patch, but it hasn't been accepted upstream yet. This API
isn't needed in GLib until WebKit is ready to start using it.
https://bugs.webkit.org/show_bug.cgi?id=200805. (c) Similarly, even if
the WebKit API was ready, that itself isn't useful until an application
is ready to start using it, and the Epiphany level work never happened.
Let's try again for GLib 2.66. Reverting this commit now just means we
gain another six months before committing to the API forever. No reason
to keep this in GLib 2.64 when nothing is using it yet.
Since we (optionally) require nanosecond precision for this
(utimes() is used on *nix), use SetFileTime(), which nominally
has 100ns granularity (actual filesystem might be coarser), instead of
g_utime (), which only has 1-second granularity.
Expand our private statbuf structure with st_mtim, st_atim and st_ctim
fields, which are structs that contain tv_sec and tv_nsec fields,
representing a timestamp with 1-second precision (same value as st_mtime, st_atime
and st_ctime) and a fraction of a second (in nanoseconds) that adds nanosecond
precision to the timestamp.
Because FILEETIME only has 100ns precision, this won't be very precise,
but it's better than nothing.
The private _g_win32_filetime_to_unix_time() function is modified
to also return the nanoseconds-remainder along with the seconds timestamp.
The timestamp struct that we're using is named gtimespec to ensure that
it doesn't clash with any existing timespec structs (MinGW-w64 has one,
MSVC doesn't).
This is required to be able to build the doc. The debian docker is still
pinned to 0.49.2 which ensure we can build with both versions of meson.
Meson 0.52.0 warns about adding -Wall flag manually, we can remove that
because warning_level=1 (the default) option already implies it.
Now that we require Meson 0.52 to build the doc, we can also pull
gtk-doc as subproject when missing from the system. This requires
to pull gtk-doc master because needed changes there haven't been release
yet.
This has the side effect of always rebuilding the doc at each build when
gtk_doc option is enabled (not by default). Most importantly, this will
enable doc check on our CI.
This reverts commit 398c048c66.
It got removed because it used to cause build issues, but now that we
have a CI let's hope it won't be a problem any more.
794c1a30bc "macro wrappers for
g_once_init_enter/leave" added this line (whose intent is unclear to me).
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1152r4.html>
"Deprecating volatile" (scheduled for inclusion in C++20) will make the
assignment expression
*(location) = (result)
deprecated when the LHS is of (non-class) volatile type, which is the case when
g_once_init_leave is expanded as part of e.g. G_DEFINE_TYPE_WITH_CODE (in
gobject/gtype.h), where location is a pointer to some
static volatile gsize g_define_type_id__volatile = 0;
Recent Clang trunk emits -Wdeprecated-volatile for it under -std=c++2a since
<https://github.com/llvm/llvm-project/commit/
4a6861a7e5b59be24a09b8b9782255d028e7aade> "[c++20] P1152R4: warn on any
simple-assignment to a volatile lvalue".
The fix is to make the assignment expression a discared-value expression by
casting it to void (which in turn requires casting the second branch of the
surrounding conditional expression to void, too; not sure what the top-level
cast to void was intended for, and whether it would still be needed under
certain circumstances).
This avoids a crash when starting Evolution, and fixes the
network-monitor and network-monitor-race test cases on my developer
workstation. (I assume the CI is not crashing due to lack of network
access there.)
Problem is that if a network already exists in the networks table,
g_hash_table_add() "destroys" (unrefs) it before adding the new one
(which we failed to ref before adding). This means we just accidentally
lost a ref. In practice, the network gets unexpectedly destroyed here
before returning.
Fixes#2020
This complements the `--glib-min-required` argument, just like the
`GLIB_MIN_REQUIRED` and `GLIB_MAX_ALLOWED` preprocessor defines which
control access to APIs in C.
Currently, it doesn’t affect code generation at all. When we next change
code generation, we will need to gate any new API usage on this
argument.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1993
This makes it consistent with the `GLIB_MIN_REQUIRED` defines which are
used for API stability/versioning in C code.
It doesn’t otherwise change the behaviour of the `--glib-min-version`
argument.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1993
Previously we would only ever run the initialization code once, but part
of it only if a non-exclusive pool was created. This caused the shared
state to be inconsistent if the first pool to be created was exclusive
and the second non-exclusive.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/2012
Rather than using an array, which requires a lot of iteration over it to
check whether a particular network is present. Using a hash table only
requires iteration in the can_reach() case, where we need to match a
mask in the networks array, rather than equal it.
This should improve performance for large numbers of routes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1925
Using the same approach as we have for code style checks (the
`style-check-diff` CI job), check the diff for any banned keywords like
‘TODO’, and also check the commit messages.
The keyword ‘TODO’ is often used by developers to indicate a part of a
commit which needs further work, and hence which shouldn’t yet be merged.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1551
g_setenv() and g_unsetenv() can never be thread-safe, so emit a message if
they are used after any threads have been spawned.
This can’t catch interactions between setenv() and g_thread_new(), or
between g_setenv() and pthread_create(), but it’ll catch most
misbehaviour in GLib-centric code.
Currently, the message is a `g_debug()` call. Eventually, I’d like to
upgrade it to a `g_warning()`, but there are a number of GLib tests
which call g_setenv() after threads have been created, and they need to
be fixed first. Emitting a `g_debug()` message gives people an
opportunity to start fixing their code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #715
