automake decided to complain about some more leftovers.
If g_dbus_connection_call() or g_dbus_proxy_call() are given a NULL callback then set the no-reply flag on the outgoing D-Bus message. https://bugzilla.gnome.org/show_bug.cgi?id=672239
GDBusProxy sets an error on a GSimpleAsyncResult and then returns without dispatching the result for completion (and leaks the result in the process). Fix that. Also add a testcase. Unfortunately, adding the testcase uncovered bug #672248. We can work around that by reordering the tests. https://bugzilla.gnome.org/show_bug.cgi?id=672249
Make it more like the one that is generated by autotools. It is true that Visual C++ has sig_atomic_t, at least for Visual C++ 2008 and later, but this is currently only used for UNIX builds of GLib, as a point of note here.
Added the definitions below, as these #defines are needed for gqsort.c #define ALIGNOF_GUINT32 4 #define ALIGNOF_GUINT64 8 #define ALIGNOF_UNSIGNED_LONG 4
printf may produce "infinity" instead of "inf". https://bugzilla.gnome.org/show_bug.cgi?id=668973
When building with MinGW/MSYS with srcdir != builddir the build fails: - to locate the generated .def files - creating libglib-gdb.py - creating libgobject-gdb.py Solved this by explicitly instructing these files to be generated in $(builddir)/... https://bugzilla.gnome.org/show_bug.cgi?id=653167
GSettings overrides are processed in such a way that alphabetically-later files have precedence over earlier files (eg: 20_ will beat 10_). Document that fact.
Pointed out by: Simon McVittie <email@example.com> https://bugzilla.gnome.org/show_bug.cgi?id=671997
And reflect the recent changes + sync with gvfs+udisks2 rules. https://bugzilla.gnome.org/show_bug.cgi?id=669797
Synchronize the error-handling logic from glibc. Users with networked filesystems in their PATH may hit ETIMEDOUT. https://bugzilla.gnome.org/show_bug.cgi?id=672201
Also, remove previous comments about sort stability in g_array_sort docs, as the method that was explained does not work. Adds a new comment about this. https://bugzilla.gnome.org/show_bug.cgi?id=672095
We need a stable sort, and we might as well always use it rather than have multiple sort versions. This picks up the glibc merge sort implementation which it uses by default for qsort, except we don't fall back to non-stable quicksort in some cases like glibc https://bugzilla.gnome.org/show_bug.cgi?id=672095
Now that we're using g_simple_async_result_set_check_cancellable() we no longer need this terrible hack of carrying the GCancellable on the GSimpleAsyncResult using qdata. See bug 672013 for more details. https://bugzilla.gnome.org/show_bug.cgi?id=672013 Signed-off-by: David Zeuthen <firstname.lastname@example.org>
Call g_simple_async_result_set_check_cancellable() after all GSimpleAsyncResult creation in order to take advantage of the new reliable cancellation feature. The guarantee of reliable cancellation fixes a bug in dbusmenu (which was already assuming that cancellation was reliable). See this bug: https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/953562 https://bugzilla.gnome.org/show_bug.cgi?id=672013 Signed-off-by: David Zeuthen <email@example.com>
...and cleanup the VS2010 property sheets a little bit
Add a function g_simple_async_result_set_check_cancellable() to provide a GCancellable that is checked for being cancelled during the call to g_simple_async_result_propagate_error(). This gives asynchronous operation implementations an easy way to provide reliable cancellation of those operations -- even in the case that a positive result has occured and is pending dispatch at the time the operation is cancelled. https://bugzilla.gnome.org/show_bug.cgi?id=672013
If the optimization is used for only having one closure handling a signal emission, then hooks will not be run, so it should be disabled when an emission hook is added. https://bugzilla.gnome.org/show_bug.cgi?id=671918
We check if the log level is in the "prefixed" list by checking it against the g_log_msg_prefix bitfield. Unfortunately we were failing to mask by G_LOG_LEVEL_MASK first, so if the FATAL bit was set (for example) then it would never match. This was the case for g_error(). https://bugzilla.gnome.org/show_bug.cgi?id=672026