Fatalize some uses of unescaped '{' in patterns

This commit follows through with our schedule of making some unescaped
literal left brace usages fatal in 5.30.  Some contexts won't be made
fatal until 5.32, and, in a partial change of plan,  others won't be
made fatal at all.

The goal since before 5.20 is to allow things like \w{foo} to be added
to the language, where the 'w' could be any suitable alphabetic.
This has already been accomplished with \b, \B (for example \b{wb}).
But various impediments have prevented generalizing this.

Another goal is to make the general quantifier, X{a,b}, syntax not so
restrictive, so that spaces can be used within the braces, and the lower
bound could be omitted.

This commit is another step towards allowing this.

Uses of some contexts have been scheduled to be made fatal in 5.30.  But
a discussion I had with Peter Rabbitson at TPC persuaded me to narrow
those contexts to the ones that we actually really need.  This commit
changes those to fatal, and the others where we had previously raised a
deprecation message are changed into a non-deprecation warning.  Keeping
this as a warning prevents a construct, where the user had intended a
quantifier but made a typo, from silently being compiled into a literal
string.

1 files changed, 69 insertions, 6 deletions

diff --git a/pod/perldiag.pod b/pod/perldiag.pod
index a200626adb..2c1fe74a87 100644
--- a/pod/perldiag.pod
+++ b/pod/perldiag.pod
@@ -6419,7 +6419,65 @@ C<undef *foo>.
 (A) You've accidentally run your script through B<csh> instead of Perl.
 Check the #! line, or manually feed your script into Perl yourself.
 
-=item Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by S<<-- HERE> in m/%s/
+=item Unescaped left brace in regex is passed through in regex; marked by S<<-- HERE> in m/%s/
+
+(W regexp)  The simple rule to remember, if you want to
+match a literal C<"{"> character (U+007B C<LEFT CURLY BRACKET>) in a
+regular expression pattern, is to escape each literal instance of it in
+some way.  Generally easiest is to precede it with a backslash, like
+C<"\{"> or enclose it in square brackets (C<"[{]">).  If the pattern
+delimiters are also braces, any matching right brace (C<"}">) should
+also be escaped to avoid confusing the parser, for example,
+
+ qr{abc\{def\}ghi}
+
+Forcing literal C<"{"> characters to be escaped will enable the Perl
+language to be extended in various ways in future releases.  To avoid
+needlessly breaking existing code, the restriction is is not enforced in
+contexts where there are unlikely to ever be extensions that could
+conflict with the use there of C<"{"> as a literal.  Those that are
+not potentially ambiguous do not warn; those that are do raise a
+non-deprecation warning.
+
+In this release of Perl, some literal uses of C<"{"> are fatal, and some
+still just deprecated.  This is because of an oversight:  some uses of a
+literal C<"{"> that should have raised a deprecation warning starting in
+v5.20 did not warn until v5.26.  By making the already-warned uses fatal
+now, some of the planned extensions can be made to the language sooner.
+The cases which are still allowed will be fatal in Perl 5.32.
+
+The contexts where no warnings or errors are raised are:
+
+=over 4
+
+=item *
+
+as the first character in a pattern, or following C<"^"> indicating to
+anchor the match to the beginning of a line.
+
+=item *
+
+as the first character following a C<"|"> indicating alternation.
+
+=item *
+
+as the first character in a parenthesized grouping like
+
+ /foo({bar)/
+ /foo(?:{bar)/
+
+=item *
+
+as the first character following a quantifier
+
+ /\s*{/
+
+=back
+
+=for comment
+The text of the message above is duplicated below to allow splain (and
+'use diagnostics') to work.  Since one is deprecated, and one not, khw
+thinks they can't be combined as one message.
 
 =item Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by S<<-- HERE> in m/%s/
 
@@ -6437,14 +6495,16 @@ Forcing literal C<"{"> characters to be escaped will enable the Perl
 language to be extended in various ways in future releases.  To avoid
 needlessly breaking existing code, the restriction is is not enforced in
 contexts where there are unlikely to ever be extensions that could
-conflict with the use there of C<"{"> as a literal.
+conflict with the use there of C<"{"> as a literal.  Those that are
+not potentially ambiguous do not warn; those that are do raise a
+non-deprecation warning.
 
 In this release of Perl, some literal uses of C<"{"> are fatal, and some
 still just deprecated.  This is because of an oversight:  some uses of a
 literal C<"{"> that should have raised a deprecation warning starting in
 v5.20 did not warn until v5.26.  By making the already-warned uses fatal
 now, some of the planned extensions can be made to the language sooner.
-The cases which are still allowed will be fatal in Perl 5.30 or 5.32.
+The cases which are still allowed will be fatal in Perl 5.32.
 
 The contexts where no warnings or errors are raised are:
 
@@ -6477,8 +6537,8 @@ as the first character following a quantifier
 =for comment
 The text of the message above is duplicated below to allow splain (and
 'use diagnostics') to work.  Since one is fatal, and one not, they can't
-be combined as one message.  And since the non-fatal one is temporary,
-there's no real need to enhance perldiag to handle this transient case.
+be combined as one message.  Perhaps perldiag could be enhanced to
+handle this case.
 
 =item Unescaped left brace in regex is illegal here in regex;
 marked by S<<-- HERE> in m/%s/
@@ -6497,13 +6557,16 @@ Forcing literal C<"{"> characters to be escaped will enable the Perl
 language to be extended in various ways in future releases.  To avoid
 needlessly breaking existing code, the restriction is is not enforced in
 contexts where there are unlikely to ever be extensions that could
-conflict with the use there of C<"{"> as a literal.
+conflict with the use there of C<"{"> as a literal.  Those that are
+not potentially ambiguous do not warn; those that are do raise a
+non-deprecation warning.
 
 In this release of Perl, some literal uses of C<"{"> are fatal, and some
 still just deprecated.  This is because of an oversight:  some uses of a
 literal C<"{"> that should have raised a deprecation warning starting in
 v5.20 did not warn until v5.26.  By making the already-warned uses fatal
 now, some of the planned extensions can be made to the language sooner.
+The cases which are still allowed will be fatal in Perl 5.32.
 
 The contexts where no warnings or errors are raised are: