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
- Insert missing word "from".
- Remove space between function name and "()" so syntax highlighting
can recognise it as a function.
- Avoid "you"/"your" when discussing the reentrancy issues of regular
UNIX signal handlers, because it gives the false impression that
these issues are applicable to g_unix_signal_source_new().
Unrelated:
- Fix missing space in documentation of g_signal_new_class_handler().
There are a few blocks in Unicode (mainly ideographs)
which default to wide. These blocks are defined in the
header comment of EastAsianWidth.txt.
We have some tests which check that unassigned codepoints
in those blocks get reported as wide, so make sure we handle
this correctly.
We need to perform multiple actions on unicode updates, so let's handle
all the commands in a single script so that we don't have to remember
all the details each time.
When compiling with C++ in MSCV, it defines the __cplusplus macro, but
that's set to an old value and it doesn't represent the current c++
standard version (unless when explicitly requested via `/Zc:__cplusplus`).
So, to enable modern features we should rely on `_MSC_LANG` instead,
which represent the value we care about.
The fix in ad23894c15 only works for
__cplusplus >= 201103L, but older C++ standards are not always less strict,
and still fail to compile the g_atomic_int_compare_and_exchange() and
g_atomic_pointer_compare_and_exchange() macros.
Apply that fix to all C++ standard versions.
Even if this implies using functions that have been added as part of
C++11 specification, this is safe because we wouldn't ever try to use the
`__atomic_...()` APIs if `__ATOMIC_SEQ_CST` is not defined, and that's part
of the very same API.
These functions may be defined as macros with different behaviors in
different c++ versions (as they rely on glib_typeof), so let's ensure
they work and compile everywhere.
When using an older C++ versions, the glib_typeof() macro is never
defined, as the C++ definition depends on __cplusplus >= 201103L, while the C
definition, which would work, depends on !defined(__cplusplus).
Allow old C++ versions to use the C macro definition for glib_typeof().
We've various macros definitions that are depending using C++ features
that may not work in all the standard versions, so recompile the cxx
tests that we have in all the ones we want to support.
These leaks happens "by design" in case that the private API
g_set_user_dirs() is used to replace directories during some tests.
And we've to leak the previously set values (if any) not to free strings
that may be used by other user code before.
In fact we're already ignoring LSAN reports for the very same reason
here.
We could create a private suppression file too, but I don't think we've to
bother with that, given that user code should never hit this path
anyways.
It's the only leak we have, sooo:
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/333
