Commit 4a4d9eb662 initially switched Meson to find the python
program using find_program('python3'). Sadly that caused a
regression, since in some cases with MSVC it would fallback to
'meson.exe runpython', which is undesired.
However, that particular code was reverted back to an also
undesired lookup method, find_installation('python3'). This
way of finding python also breaks on Windows + MSVC, in particular
when setting it up as follows:
```
winget install python
winget install meson
```
This fails building GLib with:
> python3 not found
Fix that by not passing any argument to find_installation(), which
lets Meson figure it all out by itself.
The flag is still ignored but this way we properly deprecate
at compile time without raising an unexpected criticals at runtime:
g_regex_new: assertion '(compile_options & ~G_REGEX_COMPILE_MASK) == 0' failed
and then failing to create the regex completely.
Fixes 8d5a44dc8 ("replace pcre1 with pcre2")
The validate() vfunc for GParamSpecParam returns FALSE for empty GValue,
which means the is_valid() vfunc should do the same.
This avoids a segfault when calling g_param_value_is_valid() on a
GParamSpecParam.
Fixes: #2770
Previously it was wrongly assuming that a NUL-termianted string is
passed and the whole string should be written out.
Also document this bug in the documentation of g_log_structured() to
avoid surprises when using older GLib versions.
In case we got a compilation or match error we should try to provide
some useful error message, if possible, before returning a quite obscure
"internal error" or "unknown error" string.
So rely on PCRE2 strings even if they're not translated they can provide
better information than the ones we're currently giving.
Related to: https://gitlab.gnome.org/GNOME/glib/-/issues/2691
Related to: https://gitlab.gnome.org/GNOME/glib/-/issues/2760
The tests that functionally rely on G_ENABLE_DIAGNOSTIC=1 still set it
explicitly, so that they will behave as expected when run as
installed-tests or manually.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This goes undiagnosed under normal circumstances, but is a critical
warning (which is fatal by default) under G_ENABLE_DIAGNOSTIC. This is a
programming error, so we should only exercise it under
g_test_undefined(), and only in a test that is intentionally doing this
(as in the previous commit).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This was previously exercised (probably by mistake) in
gobject/tests/type.c, but without making any assertions about what
happened, and the test would fail under G_ENABLE_DIAGNOSTIC if GLib was
compiled with debug enabled.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If a deprecated property only gets set because it is G_PARAM_CONSTRUCT
or G_PARAM_CONSTRUCT_ONLY, then there is nothing for the library user
to fix, and we should not emit a deprecation warning.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2748
Signed-off-by: Simon McVittie <smcv@collabora.com>
In case we fail unlinking a file we could close again an FD that has
been already just closed. So avoid this by unsetting it when closing.
Coverity CID: #1474462
