gcc defaults to utf-8 for both (see -fexec-charset and -finput-charset in the
gcc man page) so we should use it with msvc as well.
msvc by default uses the locale encoding unless there is a BOM, see
https://msdn.microsoft.com/en-us/library/mt708821.aspx
The tests in test_async_queue_timed() assume that g_async_queue_timeout_pop()
and in turn g_cond_wait_until() wait at least until end_time
before returning, i.e. calling g_get_monotonic_time() after the timeout should result
in a value equal or larger than the timeout end time.
For the win32 implementation of g_cond_wait_until() this isn't the case which
makes those tests fail.
There are three reasons why the function returns early:
1) The underlying API works with milliseconds and the timeout gets rounded
down, resulting in a too small timeout value.
2) In case the timeout is too large to be passed to the API it gets limited
(there is also a bug because it converts INFINITE to milliseconds while
they already are, but using INFINITE would be wrong as well, as passing
a large timeout is not the same as blocking forever really)
3) Even with the rounding changed the underlying API still returns a bit early
sometimes on my machine (relative to g_get_monotonic_time())
This changes the implementation to round up to the next millisecond (fixing 1)
and to wait again in case a timeout occurs but the end time hasn't been
reached yet (fixing 2 and 3).
This makes the test_async_queue_timed() tests pass.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
The timer tests expect that a small value for sleep does not result in
no sleep at all. Round up to the next millisecond to bring it more in line
with other platforms.
This fixes the glib/timer tests.
This makes the 'threadtests' time out since that uses small usleeps a lot and
until now didn't wait at all, but now always waits a msec. Reduce the amount
of tests done on Windows to get the runtime down to something reasonable again.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
Our minimum requirement is already greater than that, so we don't need
to add checks there. We can always add -Wl,-framework,CoreFoundation
flag.
Fixes#1380.
For g_autolist and g_autoslist, the cleanup func was cast to
GDestroyNotify before being passed to g_(s)list_free_full. This cast
provokes GCC 8 to emit a warning if the return type is not void:
…/gmacros.h:462:99: warning: cast between incompatible function types
from … to 'void (*)(void *)' [-Wcast-function-type]
Cast to 'void (*)(void)' first, which suppresses the warning as
recommended by the GCC documentation. g_autoptr remains untouched.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/1382
In commit f49a93b207
from bug https://bugzilla.gnome.org/show_bug.cgi?id=791342
we added two new static inline cleanup helpers in case a type was
used inside a list.
These functions will commonly be unused.
In rpm-ostree, we run a build using `CC=clang -Werror=unused` because
it catches `g_autofree char *foo = NULL;` as unused, but GCC doesn't.
When trying to update to F28 with a newer glib, our CI fell over on this.
Mark all of the autocleanups as "maybe unused".
Visual Studio x64 builds do not allow inline assembly code, so we need
to re-add the code that disables inline assembly when we build with
Visual Studio for x64 builds, as we did before. This is necessary when
we update the included valgrind.h.
GitLab can then use this to annotate each pipeline with its code
coverage statistics. It can only use one figure, so we choose lines
(rather than function or branch coverage) since it’s the most intuitive
figure.
This parses the ‘lines’ line from output like:
Overall coverage rate:
lines......: 76.7% (108959 of 142122 lines)
functions..: 80.7% (10294 of 12763 functions)
branches...: 51.3% (50226 of 97953 branches)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The output of the %p type is implementation defined and on Windows we get
leading zeros depending on the pointer type size. Instead of adding
ifdeffery use g_snprintf() to generate the expected message.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
