Bug#1118572: libpcre2-8-0: pcre2 10.47 behaviour change: different error for ^(a)\g{3

[Simon McVittie]

Package: libpcre2-8-0,libglib2.0-0
Severity: serious
Control: found -1 pcre2/10.47-1
Control: found -1 glib2.0/2.86.1-1
User: debian-ci at lists.debian.org
Usertags: regression
Tags: ftbfs experimental
Control: block 902060 by -1

With the new pcre2 in experimental, GLib's "as-installed" tests fail 
during autopkgtest. This can most easily be reproduced in a container 
(in this example Podman, but use whatever is your favourite 
chroot/container techology):

$ podman run --rm -it docker.io/debian:sid-slim
# sed -i -e 's/Suites: sid/& experimental/' /etc/apt/sources.list.d/debian.sources
# apt update
# apt upgrade
# apt install --no-install-recommends libglib2.0-tests
# /usr/libexec/installed-tests/glib/regex; echo $?
...
0
# apt install libpcre2-8-0/experimental
# /usr/libexec/installed-tests/glib/regex ; echo $?
...
not ok /regex/new-fail/78 - ERROR:../../../glib/tests/regex.c:133:test_new_fail: assertion failed (error == (g-regex-error-quark, 157)): Error while compiling regular expression ?^(a)\g{3? at char 8: syntax error in subpattern number (missing terminator?) (g-regex-error-quark, 0)
Bail out!
Aborted                    (core dumped) /usr/libexec/installed-tests/glib/regex
134

I'm reasonably sure this would also make glib2.0 FTBFS (hence the ftbfs 
tag) although I haven't verified this.

The test failure is that GLib is expecting that compiling the 
(incomplete) regex "(a)\g{3" will produce PCRE2_ERROR_BACKSLASH_G_SYNTAX 
(which it translates to GRegexError number 157, 
G_REGEX_ERROR_MISSING_BACK_REFERENCE), but in fact it saw some error code 
that is not specifically handled by translate_compile_error() in 
glib/gregex.c, resulting in the default error, G_REGEX_ERROR_COMPILE.

Was this an intentional behaviour change in PCRE?

There might be other assertion failures after this one is addressed, I 
haven't checked that yet.

    smcv