ENHANCED: use pcre2 library instead of pcre1 #11
Conversation
|
I just realized that I've been doing the options wrong. Unlike PCRE1, where there's just one set of flags for both compile and match, there are 4 different flags and I need to distinguish them. E.g.: So, I need to rewrite the options handling. :( |
|
I've pushed a new squashed change - ready for review. |
|
When you've finished reviewing the code, I'll prepare a git patch file for the other changes (#2 (comment)). These aren't needed for building and testing on Linux, but are possibly needed for other kinds of builds. (I'm delaying creation of the patch file, to be sure it's against the latest version of the master) |
|
I've sent 3 patches to bugs@swi-prolog.org, to be applied after this PR is applied. |
kamahen
force-pushed
the
pcre2
branch
2 times, most recently
from
1d3fbf4
to
76a83aa
Compare
- Issue SWI-Prolog#2 - Numerous small bug fixes and enhancements (e.g., handling of duplicate options, capture_type, error checking). - This commit takes advantage of refactoring that was done on the pcre1 code to make it easier to handle the pcre2 options (which are both more numerous and have a different underlying API). - Added new pcre2 options - Removed some obsolete options, preserving backwards compatibility where possible - The meaning of optimise(true) has changed - it now calls the JIT compiler - Renamed bsr(...) and newline(...) options to bsr2(...) and newline2(...) because the pcre2 interface has changed - compat(javascript) is replaced by alt_bsux(true) and extra_alt_bsux(true) - Code improvements: use `uint32_t` wherever possible instead of `unsigned` or `int` - Does not use the new pcre2_substitute() for re_replace/{4,5}, re_split/{3,4}, re_foldl/6 (however, some improvements have been made to the APIs for these). - Added test cases
This is a preliminary commit, to review some design decisions:
bsr2,newline2because the underlying number codes changedpcre2_compile_context_create())There are also some TODOs that will be removed.
Please verify that I've followed the C formatting conventions (it's not a style that I normally use).
When all the reviews are done (including a detailed check of all the options), the various commits will be squashed into a single commit.