fixed #10610 - added support for PCRE2

[firewave]

No description provided.

[Harvester57]

Do you still need pcre.h if you are using pcre2.h ? I'm trying to build with CMake on Debian Trixie, for which libpcre3-dev is not available, and the build still fails because CMake cannot detect pcre.h

[firewave]

Do you still need pcre.h if you are using pcre2.h ?

No.

This is still WIP. I have not added build options separating PCRE from PCRE2 yet.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Harvester57]

Looking almost good with cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DHAVE_RULES=ON -DUSE_PCRE2=ON -DDISABLE_PCRE1=ON : https://github.com/Harvester57/docker-cppcheck/actions/runs/24076359858/job/70225683963 👍

[firewave]

almost good

Hence it still being a draft. 🙂

[loqs]

@firewave do you need any help completing this pull request? I can open pull requests against your branch to complete adding support for PCRE2 and address the issues I have found so far.

[firewave]

@firewave do you need any help completing this pull request? I can open pull requests against your branch to complete adding support for PCRE2 and address the issues I have found so far.

@loqs Thanks, but all the implementation work is done.

The main issue is how to proceed with the deprecation/transition steps for PCRE to a new default. I had an idea on how to proceed but since std::regex has always been hot garbage (and is also currently being broken in Visual Studio 2022) the steps are not that obvious anymore and I am currently not in the space of mind of thinking it through properly. It is definitely a multi-step process. Another annoyance is to cover the steps in the CI.

[loqs]

@loqs Thanks, but all the implementation work is done.

So all the following is fixed but not pushed yet?:

• Building with only PCRE1
• Building with only PCRE2
• Memory leak of PCRE2 match
• Return values not checked in PCRE2 code path
• PCRE2 handling of capture groups does not match PCRE1
• Mismatched test expectations
• Missing CI integration
• Missing Makefile integration
• Missing documentation

Should Arch Linux just disable rules for now in order to be able to drop PCRE1 or will this pull request be merged before a transition to something other than PCRE2?