GLib uses PCRE for its regex support. There are a number of problems that need to be addressed:

* GLib embeds an old copy of PCRE; it needs to go away. This is already being discussed in bug 740573.

* GLib's PCRE support is at level of PCRE 8.31, a very old version, so it's missing the additions since then; bug 689791 is about updating it. And the corresponding wip/pcre-update branch is up to 8.35 (iirc?).

* GLib doesn't allow using PCRE's JIT which speeds up matching (bug 679155).

* PCRE itself is deprecated in favour of a new API called PCRE2. The old PCRE will only receive sporadic bugfix releases for a some time.


So there needs to be a fundamental decision about what to do with GRegex. I think these are the alternatives:

[A] (Least work) Deprecate GRegex (and perhaps later remove it) and recommend users to use PCRE2 directly.

[A'] Deprecate GRegex, drop PCRE use internally making GRegex a no-op (i.e. always return NULL and error from g_regex_new). Might be considered an ABI break.

[B] Update GRegex to use PCRE2 internally (and expose the JIT functionality).

[C] A and B.