Since we have raised our minimum CMake version to 3.15, this updates the
default value of the "CMP0091" backwards-compatibility policy, such that
PCRE2_STATIC_RUNTIME is now broken (since 10.45 when
cmake_minimum_required was increased).
We can remove this flag, since the new built-in
CMAKE_MSVC_RUNTIME_LIBRARY provides the same behaviour.
Currently, pcre2test prints the erroroffset as a simple number, which makes it hard to see in the test output where it's actually pointing.
I have added printing of the relevant portion of the pattern, to show visually where the offset points.
There is also a new function error_direction() where I have started to classify which PCRE2 errors point to the left or right of the erroroffset. When I have fixed this all to be consistent to my satisfaction, I will document this so that clients have a better way to indicate which character is wrong in a regex.
This ensures that (most) compatible editors will insert tabs into the makefiles and spaces elsewhere. We also don't want trailing whitespace to be stripped when we edit the test files. Finally, it helps to open testinput1 in Latin-1 and testinput2 in UTF-8 mode. All this can be automated.
The editorconfig file should work with any text editor - although note that VS Code needs an extension to make use of it.
The problem is that the Readline/zlib include paths were being included
before our own include path (wrong import order). This caused a problem
if the zlib include path was /usr/local/include, and that directory
happened to unfortunately contain a pcre2.h file for an (older) version
of PCRE2.
Additionally, I have attempted to clean up some CMake issues to make the
package's build interface cleaner, in particular, avoiding polluting the
parent directory's include path with our config.h file (if PCRE2 is being
included as a subdirectory).
This re-adds changes from Theodore's commit:
def175f4a9
and partially reverts changes from Carlo's commit:
92d56a1f7c
---------
Co-authored-by: Theodore Tsirpanis <teo@tsirpanis.gr>
It's not available on Windows, but we hadn't noticed this because it's
provided by the Git for Windows tools which I have installed. This is
not good practice to require these tools as a build dependency.
I have replaced "head -1" with "pcre2grep -m1 .*" which matches and
prints the first line. For consistency, I have made the same change on
Unix.
* The primary purpose of pcre2_next_match() is to make it much easier for
PCRE2 clients to iterate over matches, without needing an advanced knowledge
of regular expressions.
* Secondly, we can simplify our own code by merging the three duplicate
implementations of the /g global match behaviour: pcre2demo, pcre2_substitute,
and pcre2test.
* Thirdly, as I look closely at the issue, I can improve the documentation.
* Fourthly, I would like to actually simplify the logic, removing a complex loop
which makes several match attempts, swallows duplicate matches, and more.
We can have identical behaviour with a simple retry using
PCRE2_NOTEMPTY_ATSTART.
We won't implement more advanced/alternative global replacement strategies, but we can at least write a few sentences explaining how to do it in application code.
The value `""` is a `char[1]` array with a single zero byte. It should not be cast to a PCRE2_SPTR, which is a pointer to an array of 1/2/4-byte values. It may not even have the required pointer alignment for a PCRE2_SPTR (in 16 or 32 bit mode).
The pointer is never dereferenced anyway, since the length is zero.
Reported by Microsoft's OACR linter.
As a quick and easy fix, I'll just set it a non-null value with the shortest possible length (no zero-length arrays allowed in C).
This has the best chance of silencing linters that want us to have a non-NULL value for the zero-length pointer.
Both the Autoconf and CMake build systems are updated to detect linker support for symbol versioning.
Currently, Linux, Solaris, and FreeBSD are tested and working. Windows (COFF) and macOS (Mach-O) have no symbol versioning.
There is an Autoconf/CMake flag to opt out of the versioning behaviour.
Followup to #722
* Fix Windows build warning by adding PCRE2_STATIC to pcre2test
* Remove unnecessary `.linkLibc()` command, now that we have `link_libc = true` in the Module declarations
* Update the old `std.Build.Step.Compile.create(...)` calls to the brand-new `b.addLibrary(...)` function. They added this exactly for our use-case, to allow dynamically selecting between `addStaticLibrary/addDynamicLibrary` variants.
* Bump zig stack usage in CI
This is important for e.g. glib/gio, which also has an internal config.h, and fails to compile, as it often picks up the pcre2 config.h first.
---------
Co-authored-by: Nicholas Wilson <nicholas@nicholaswilson.me.uk>
With the release of zig 0.14.0, there are some breaking changes to syntax in build.zig.
Here, we drop support for zig 0.13, and add support for 0.14. There does not seem to be any advantage to try and support both simultaneously (nor did the zig maintainers make this easy).
---
Co-authored-by: qaptoR <rocco.ruscitti@outlook.com>
We have four files which have .c extensions, but which are actually #included rather than treated as their own compilation unit.
This goes against conventions - Autotools, CMake, and Bazel all assume that the .h/.c distinction indicates which files are compilation units.
pcre2_jit_match.c -> _inc.h
pcre2_jit_misc.c -> _inc.h
pcre2_printint.c -> _inc.h
pcre2_ucptables.c -> _inc.h
