Move it to a separate content page as there is no `GDBusIntrospection`
type to hang the rest of the documentation off.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Adding it all to the docs for the `GDBusError` enum seemed a bit much,
so I moved it to its own content page.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
These are one-time leaks, and happen if the util dir paths are built via
these code paths, and then subsequently overwritten using
`g_set_user_dirs()` (typically as part of a unit test).
The additions to `glib.supp` correspond to the `g_ignore_leak()` calls
in `gutils.c`. Unfortunately `g_ignore_leak()` only affects asan, not
valgrind.
See https://gitlab.gnome.org/GNOME/glib/-/jobs/3294034
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The `g_content_type_guess_for_tree` function segfaults currently when
processing filenames that are not valid unicode strings. Let's use the
`g_filename_to_utf8` and `g_utf8_make_valid` functions before other
processing to prevent that.
Let's also add a test for it to avoid this in future.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3168
g_option_context_parse()/g_application_run()/g_test_init() for
convenience also call g_set_prgname(), when the prgname is unset at this
point. This was racy.
Fix the race by using an atomic compare-and-exchange and only reset the
value, if it is unset still.
g_set_application_name() guards against being reset, but it doesn't
remember whether it was set, it only checks whether g_application_name
was set to non-NULL. When allowing g_set_application_name(NULL) that leads
to odd behaviors, like:
g_set_application_name(NULL);
g_set_application_name("foo");
would not warn.
Disallow that and assert against a NULL application_name.
Note that application_name argument is also not marked as "(nullable)".
Now that libgirepository uses `GI_AVAILABLE_IN_*` macros, that’s what
controls symbol visibility. The `_` prefixes are redundant, and out of
keeping with the rest of GLib.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Now that libgirepository is inside glib.git, it’s guaranteed access to
all the latest APIs, so there’s no need for version checks.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Rather than a mix of structs being in `GI` and their methods being in
`g_`.
We’ve chosen not to use the `g_` namespace because a number of the
libgirepository class names are quite generic, so we’d end up with
confusing symbols like `GScopeType` and `GArgument`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
After bumping the major version number, we don’t need backwards
compatibility any more.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
These are one-time allocations which are still reachable at the end of
the process. They cause warnings like this in valgrind:
```
==14408== 128 bytes in 1 blocks are definitely lost in loss record 1,287 of 1,403
==14408== at 0x4847A40: realloc (vg_replace_malloc.c:1649)
==14408== by 0x48CCD6E: g_realloc (gmem.c:201)
==14408== by 0x48F4CB1: g_string_expand (gstring.c:82)
==14408== by 0x48F4D59: g_string_sized_new (gstring.c:113)
==14408== by 0x48F4D91: g_string_new (gstring.c:134)
==14408== by 0x48A5805: g_build_path_va (gfileutils.c:1929)
==14408== by 0x48A62D1: g_build_filename_va (gfileutils.c:2222)
==14408== by 0x48A63FE: g_build_filename (gfileutils.c:2316)
==14408== by 0x491CD89: g_build_user_data_dir (gutils.c:1879)
==14408== by 0x491CDCF: g_get_user_data_dir (gutils.c:1920)
==14408== by 0x4B51E53: _g_content_type_set_mime_dirs_locked (gcontenttype.c:145)
==14408== by 0x4B51F33: g_content_type_set_mime_dirs (gcontenttype.c:194)
==14408== by 0x40C222: main (desktop-app-info.c:1880)
```
For example in https://gitlab.gnome.org/GNOME/glib/-/jobs/3278564
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
When `--attributes` is specified and doesn’t include `standard::name` in
its list, `gio` would print a critical warning from the (mandatory) call
to `g_file_info_get_name()`.
Fix that by making the call to `g_file_info_get_name()` optional.
Add a unit test too.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3158
It gives nowhere near full coverage, but it’s something we can build on
in future.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3158
Helps: #2950
