[glib: 2/3] gregex: Drop explanation G_REGEX_JAVASCRIPT_COMPAT

[Marco Trevisan <marcotrevi src gnome org>]

commit 664ee9ca6afcc3e08c99f0918982e9d2e22f34a8
Author: Guido Günther <agx sigxcpu org>
Date:   Fri Sep 23 15:27:49 2022 +0200

    gregex: Drop explanation G_REGEX_JAVASCRIPT_COMPAT
    
    It's not supported as of glib 2.74

 glib/gregex.c | 12 ------------
 1 file changed, 12 deletions(-)
---
diff --git a/glib/gregex.c b/glib/gregex.c
index 6b22f1f151..50abeee89f 100644
--- a/glib/gregex.c
+++ b/glib/gregex.c
@@ -89,18 +89,6 @@
  * unescaped "#" outside a character class is encountered. This indicates
  * a comment that lasts until after the next newline.
  *
- * When setting the %G_REGEX_JAVASCRIPT_COMPAT flag, pattern syntax and pattern
- * matching is changed to be compatible with the way that regular expressions
- * work in JavaScript. More precisely, a lonely ']' character in the pattern
- * is a syntax error; the '\x' escape only allows 0 to 2 hexadecimal digits, and
- * you must use the '\u' escape sequence with 4 hex digits to specify a unicode
- * codepoint instead of '\x' or 'x{....}'. If '\x' or '\u' are not followed by
- * the specified number of hex digits, they match 'x' and 'u' literally; also
- * '\U' always matches 'U' instead of being an error in the pattern. Finally,
- * pattern matching is modified so that back references to an unset subpattern
- * group produces a match with the empty string instead of an error. See
- * pcreapi(3) for more information.
- *
  * Creating and manipulating the same #GRegex structure from different
  * threads is not a problem as #GRegex does not modify its internal
  * state between creation and destruction, on the other hand #GMatchInfo