Skip to content
This repository was archived by the owner on Jun 1, 2023. It is now read-only.

Less m/{}/ Unescaped left brace in regex is deprecated here warnings #362

Closed
rurban opened this issue May 16, 2018 · 2 comments
Closed

Less m/{}/ Unescaped left brace in regex is deprecated here warnings #362

rurban opened this issue May 16, 2018 · 2 comments
Labels
Milestone

Comments

@rurban
Copy link
Member

rurban commented May 16, 2018

automake and more widespread utils does not need to be plagued by spurious "Unescaped left brace in regex" warnings, when they don't need to be quoted.
The few cases where { is used for a special unicode group can be easily detected in regcomp.

Name: \N{}
Property: \p{}, \P{}
Break: \b{}, \B{}
Code: \x{}, \o{}
Group: \g{}

perlre.pod:
(If a curly bracket occurs in any other context and does not form part of a
backslashed sequence like "\x{...}", it is treated as a regular character.
However, a deprecation warning is raised for all such occurrences, and in Perl
v5.26, literal uses of a curly bracket will be required to be escaped, say by
preceding them with a backslash ("{") or enclosing them within square brackets
("[{]"). This change will allow for future syntax extensions (like making the
lower bound of a quantifier optional), and better error checking of quantifiers.)

perldiag.pod:

   Unescaped left brace in regex is deprecated here (and will be fatal in
    Perl 5.30), passed through in regex; marked by <-- HERE in m/%s/
    (D deprecated, regexp) The simple rule to remember, if you want to
    match a literal "{" character (U+007B "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
    "\{" or enclose it in square brackets ("[{]"). If the pattern
    delimiters are also braces, any matching right brace ("}") should also
    be escaped to avoid confusing the parser, for example,

     qr{abc\{def\}ghi}

    Forcing literal "{" 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 "{" as a literal.

    In this release of Perl, some literal uses of "{" are fatal, and some
    still just deprecated. This is because of an oversight: some uses of a
    literal "{" 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.

    The contexts where no warnings or errors are raised are:

    *   as the first character in a pattern, or following "^" indicating
        to anchor the match to the beginning of a line.

    *   as the first character following a "|" indicating alternation.

    *   as the first character in a parenthesized grouping like

         /foo({bar)/
         /foo(?:{bar)/

    *   as the first character following a quantifier

         /\s*{/

Unescaped left brace in regex is illegal here in regex; marked by <-- HERE
in m/%s/

For the proposed extensions: optional lower bound of a quantifier {,\d}, and better error checking of quantifiers we need {, or {\d, not justifying punishing all old usages of hash{key}, esp. since those keys are not literal numbers or commas.

@rurban rurban changed the title m/{}/ warning: allow but with the \N{} and friends syntax Less m/{}/ Unescaped left brace in regex is deprecated here warnings May 16, 2018
@rurban
Copy link
Member Author

rurban commented Sep 2, 2018

Note that p5p decided on the opposite, to make these harmful unnecessary warnings even fatal with 5.30.

rurban added a commit that referenced this issue Oct 4, 2018
Only check for
  Name:  \N{}
  Property: \p{}, \P{}
  Break: \b{}, \B{}
  Code:  \x{}, \o{}
  Group: \g{}
and allow other chars before a {

automake and more widespread utils does not need to be plagued by spurious
"Unescaped left brace in regex" warnings, when they dont need to be quoted.
Undeprecate those new errors, there's nothing more to reserve (yet).

strpbrk is C89.
Fixes [cperl #362]
@rurban
Copy link
Member Author

rurban commented Oct 4, 2018

Merged into v5.29.0c, should be backported to v5.28.1c too

@rurban rurban closed this as completed Oct 4, 2018
@rurban rurban added the bug label Oct 4, 2018
@rurban rurban added this to the v5.28.1c milestone Oct 4, 2018
rurban added a commit that referenced this issue Oct 5, 2018
Only check for
  Name:  \N{}
  Property: \p{}, \P{}
  Break: \b{}, \B{}
  Code:  \x{}, \o{}
  Group: \g{}
and allow other chars before a {

automake and more widespread utils does not need to be plagued by spurious
"Unescaped left brace in regex" warnings, when they dont need to be quoted.
Undeprecate those new errors, there's nothing more to reserve (yet).

strpbrk is C89.
Fixes [cperl #362]

(cherry picked from commit 17e2b8d)
rurban added a commit that referenced this issue Mar 15, 2019
perl5 really went ahead with fatalizing too many occurences
of unescaped {} with every prefix, cperl faializes only the
actually reserved character prefixes: \NpPbBxog. [cperl #362]

Remove the old (and unsed) deprecation messages.

See commit 76416d1 - Karl Williamson
rurban added a commit that referenced this issue Mar 16, 2019
perl5 really went ahead with fatalizing too many occurences
of unescaped {} with every prefix, cperl fatalizes only the
actually reserved character prefixes: \NpPbBxog. [cperl #362]

Remove the old (and unused) deprecation messages.

See commit 76416d1 - Karl Williamson
rurban added a commit that referenced this issue Mar 18, 2019
perl5 really went ahead with fatalizing too many occurences
of unescaped {} with every prefix, cperl fatalizes only the
actually reserved character prefixes: \NpPbBxog. [cperl #362]

Remove the old (and unused) deprecation messages.

See commit 76416d1 - Karl Williamson
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant