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
Building the references requires libraries with all their symbols
available. Passing `-Dgtk_doc=true` and `-Ddefault_library=static`
should be considered a configuration error.
Though unlikely to happen, it may happen that newly created file
descriptor take the value 0 (stdin), 1 (stdout) or 2 (stderr) if one
of the standard ones have been dismissed in between. So, it may
confuse the program if it is unaware of this change.
The point of this patch is to avoid a reasign of standard file
descriptors on newly created ones.
Closes issue #16
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>
desktop-app-info test may fail when repeated with multiple concurrent
processes because the actions test relies on checking the existence of
in the shared build directory, so by doing something like:
meson test -C _build desktop-app-info -t 0.3 --repeat 80
We may end up in timeout errors, because we are waiting for files that
have been already deleted by other processes.
To avoid this, let's rely on writing the files on `$G_TEST_TMPDIR` env
variable, that is always set and unique, given that we're using the
G_TEST_OPTION_ISOLATE_DIRS test option.
Those tools are not needed at runtime for typical applications,
distributions typically package them separately.
This makes `meson install --tag runtime` skip installation of those
tools. Omitting `--tag` argument will still install them, as well as
with `--tag bin,bin-devel`.
See https://mesonbuild.com/Installing.html#installation-tags.
Do not store jit status for regex unless during initial compilation.
After that, decide whether to use it depending on matching options.
In fact there are some matching options that are incompatible with JIT,
as the PCRE2 docs states:
Setting PCRE2_ANCHORED or PCRE2_ENDANCHORED at match time is not
supported by the just-in-time (JIT) compiler. If it is set, JIT
matching is disabled and the interpretive code in pcre2_match() is
run. Apart from PCRE2_NO_JIT (obviously), the remaining options are
supported for JIT matching.
Fixes: GNOME/gtksourceview#283
There's no much point of pre-allocating offsets given that we're doing
this when needed if only have matches to store.
So let's just allocate the spaces for the dummy offset we depend on,
while allocate the others on demand.
While the ovector count would include all the allocated space, we only
care about the actual match values, so avoid wasting allocations and
just use the ones we need to hold the offsets.
In case PCRE2 returns an empty match
This can be easily tested by initializing the initial match data to a
value that is less than the expected match values (e.g. by calling
pcre2_match_data_create (1, NULL)), but we can't do it in our tests
without bigger changes.
We're using int for every size value while PCRE uses uint_32t or
PCRE2_SIZE (size_t in most platforms), let's use the same types to avoid
using different signs.
In case recalc_match_offsets() failed we were just returning, but in
such case, per the documentation we should still set the match_info (if
provided) and free the pcre2 code instance.
So let's just break the loop we're in it, as if we we've no matches set.
This also avoids re-allocating the offsets array and potentially
accessing to unset data.
In case we're getting NO-MATCH "errors", we were still recomputing the
match offsets and taking decisions based on that, that might lead to
undefined behavior.
Avoid this by just returning early a FALSE result (but with no error) in
case there's no result to proceed on.
Fixes: #2741
As per the PCRE2 port we still used to try to map the old GRegex flags
(PCRE1 based) with the new PCRE2 ones, but doing that we were also
mixing flags with enums, leading to unexpected behaviors when trying to
get new line and BSR options out of bigger flags arrays.
So, avoid doing any mapping and store the values as native PCRE2 flags
internally and converting them back only when requested.
This fixes some regressions on newline handling.
Fixes: #2729Fixes: #2688Fixes: GNOME/gtksourceview#278
