The deprecated construct '@0@'.format(h) (where h is a file object)
expanded to the filename relative to the project root, which in this
particular case happens to be what we wanted:
`--c-include=gio/gunixmounts.h` resulted in a recommendation to
`#include <gio/gunixmounts.h>` and so on. Replacing it with
h.full_path() resulted in GIR XML and documentation that recommended
constructs like `#include </home/me/src/glib/gio/gunixmounts.h>`,
which is not what was intended (and caused new differences between
different architectures' Gio-2.0.gir on multiarch systems, which is
how I discovered this).
Hard-coding `gio/` and appending the basename of the header seems like
the simplest non-deprecated spelling that will do what we wanted.
Fixes: 51e3e7d9 "build: Bump Meson dependency to 1.4.0"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3564
Signed-off-by: Simon McVittie <smcv@collabora.com>
This tests the C++ version of g_win32_clear_com() as there are some
COM interfaces that are only available in C++, such as DirectWrite from
the headers shipped with the Windows SDK.
This mimicks the test for the same function in glib/tests/win32.c but
done in a C++ fashion.
This is quite similar in concept to what g_clear_object() does, except
that is meant to deal with Windows COM objects. Note that there is a
separate C++ version available for this as there are COM interfaces that
are available in C++ only, such as DirectWrite that is shipped with the
Windows SDK (albeit a C interface is provided with the mingw-w64
toolchain.
This will call `->Release()` on the non-NULL COM object referenced by its
pointer and sets the COM object to NULL; if the pointer refers to a
NULL COM object, this is a no-op.
None of these comments have been ported to gi-docgen format properly
yet, but let’s at least fix the backslash escaping so that
`G_DIR_SEPARATOR_S` can be documented usefully.
A full port of this file to gi-docgen format can happen in future.
Spotted on
https://discourse.gnome.org/t/escaped-char-in-glib-dir-separator-s-doc/25607.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This will allow us to test that it actually still works, which is
important for being able to make releases, because once we push a tag,
there’s no going back. The release can’t happen if `dist-job` then fails
on that tag.
Sigh.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
If `-Ddocumentation=true` is specified without
`-Dintrospection=enabled`, warn the user. They might expect the
documentation to be built, but it won’t.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This means that the documentation can actually be generated, which was
broken before. Building the documentation requires `enable_gir`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
As per the previous few commits, explicitly document the established
reference counting semantics of the method call closure for
`g_dbus_connection_register_object_with_closures()`.
This isn’t ideal, but
`g_dbus_connection_register_object_with_closures()` has had these
semantics for 10 years now, and it’s a bit late to change them to
something neater.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3559
It’s not leaked, it’s transferred forwards to the eventual
`g_dbus_method_invocation_return_*()` call.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3559
This reverts commit 092fedd5f0.
This was not the right change to make, and I shouldn’t have accepted the
MR. The situation is laid out in this comment:
https://gitlab.gnome.org/GNOME/glib/-/issues/2600#note_1385050
tl;dr: The reference on the `GDBusMethodInvocation` which is transferred
in to the `GDBusInterfaceMethodCallFunc` is balanced by a reference
transferred to `g_dbus_method_invocation_return_*()`. This is how the
refcounting has always worked for these functions, and even if we’d
probably arrange things differently if the code was written now, we
can’t change those semantics without breaking API.
In particular, bindings have various bits of custom code to account for
these reference tranfers (since they can’t be represented using
gobject-introspection annotations), so changing the semantics will break
bindings.
Fixes: #3559
Parts of the `dbus-appinfo` test need support for converting an FD to a
path, and Hurd doesn’t currently allow that (see
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4396#note_2279923).
Since there’s no fix for that visible in the medium term (new kernel
APIs will need to be added), skip parts of the `dbus-appinfo` test which
require that functionality for now.
This prevents the whole test from failing, and means we can usefully get
results from the parts of it which don’t depend on converting FDs to
paths.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3538
Don’t want any argument escaping problems, given that some of these
variables can be controlled by unprivileged users who are running CI
jobs.
The except:variables and rules:if lines don’t need to be quoted because
they are [GitLab CI/CD Variable
Expressions](https://docs.gitlab.com/ee/ci/jobs/job_rules.html#cicd-variable-expressions)
rather than bash script.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It doesn’t list all mounts, only the ones you’d expect to see in a file
chooser sidebar.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3555
The docs for the constructed vfunc make it clear that when called
constructed properties are already set. However, the first place where a
user would look for is the flag's documentation.
A settings schema that extends another schema should return TRUE for
all keys that are present in the extended schema. The list of keys
returned by list_keys() already includes these,
so it makes sense to include them in has_key().
Signed-off-by: Johannes Marte <johannes.marte@wolfvision.net>
Move details about the `log_domain` parameter being `NULL` or an empty string
for the default application domain from argument descriptions to the main
function descriptions.
This ensures concise argument descriptions while providing a clear
explanation of exceptions in the function body.
Add a missing `(nullable)` annotation for the `log_domain` parameter in the
`GLogFunc` callback. This ensures consistency with the documentation and
usage in functions like `g_log_set_handler`, where `log_domain` can be `NULL`.
Without this annotation, the GIR file generated from the C source does not
reflect the nullability of `log_domain`, leading to potential issues in
language bindings and other introspection-based tools.
This change updates the documentation in `glib/gmessages.c` to include the
nullable annotation and clarifies the expected behavior of the `GLogFunc`
callback.
Fixes#3552
