1From 664ee9ca6afcc3e08c99f0918982e9d2e22f34a8 Mon Sep 17 00:00:00 2001 2From: =?UTF-8?q?Guido=20G=C3=BCnther?= <agx@sigxcpu.org> 3Date: Fri, 23 Sep 2022 15:27:49 +0200 4Subject: [PATCH] gregex: Drop explanation G_REGEX_JAVASCRIPT_COMPAT 5 6It's not supported as of glib 2.74 7 8Conflict:NA 9Reference:https://gitlab.gnome.org/GNOME/glib/-/commit/664ee9ca6afcc3e08c99f0918982e9d2e22f34a8 10 11--- 12 glib/gregex.c | 12 ------------ 13 1 file changed, 12 deletions(-) 14 15diff --git a/glib/gregex.c b/glib/gregex.c 16index 6b22f1f151..50abeee89f 100644 17--- a/glib/gregex.c 18+++ b/glib/gregex.c 19@@ -89,18 +89,6 @@ 20 * unescaped "#" outside a character class is encountered. This indicates 21 * a comment that lasts until after the next newline. 22 * 23- * When setting the %G_REGEX_JAVASCRIPT_COMPAT flag, pattern syntax and pattern 24- * matching is changed to be compatible with the way that regular expressions 25- * work in JavaScript. More precisely, a lonely ']' character in the pattern 26- * is a syntax error; the '\x' escape only allows 0 to 2 hexadecimal digits, and 27- * you must use the '\u' escape sequence with 4 hex digits to specify a unicode 28- * codepoint instead of '\x' or 'x{....}'. If '\x' or '\u' are not followed by 29- * the specified number of hex digits, they match 'x' and 'u' literally; also 30- * '\U' always matches 'U' instead of being an error in the pattern. Finally, 31- * pattern matching is modified so that back references to an unset subpattern 32- * group produces a match with the empty string instead of an error. See 33- * pcreapi(3) for more information. 34- * 35 * Creating and manipulating the same #GRegex structure from different 36 * threads is not a problem as #GRegex does not modify its internal 37 * state between creation and destruction, on the other hand #GMatchInfo 38-- 39GitLab 40 41