Closed Bug 190685 Opened 22 years ago Closed 21 years ago

Unexpected SyntaxError for /^{(.*)\}$/

Categories

(Rhino Graveyard :: Core, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: user, Assigned: rogerl)

References

()

Details

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Build Identifier: Rhino  2003-01-25 CVS

Already applied fix for the bug 189898 broke js1_2/Objects/toString-001.js test
case which now fails with:

*-* Testcase js1_2/Objects/toString-001.js failed:
Expected exit code 0, got 3
Testcase terminated with signal 0
Complete testcase output was:
js: uncaught JavaScript exception: SyntaxError: Invalid quantifier {


The test case fails when it declares the following regular expression:

/^{(.*)\}$/



Reproducible: Always

Steps to Reproduce:
1. Run Rhino shell
2. Enter there the foolowing regular expression:
/{\}/
Actual Results:  
js: uncaught JavaScript exception: SyntaxError: Invalid quantifier {


Expected Results:  
/{\}/
Reassign to Roger
Assignee: nboyd → rogerl
Although the Ecma standard does not allow standalong {, but SM and js in MSIE
allows it.
Sigh. Once the mega-fix for 85721 goes in, SM will fail on this, too. ECMA
clearly disallows this, but backwards and MSIE compatibility arguments are stronger.

Fix checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
OK, double-sigh. Now regress-188206 will fail because we explicitly included '{'
as a bad thing resulting from that bug report (bug 188206). Looking for
suggestions, back out this fix and stay with ECMA, or officially support '{' and
change the test ?
FWIW:

The test js1_2/Objects/toString-001.js uses the regexp in question
to check the output of the Object.prototype.toString() function.

Such output is expected to begin and end with a curly bracket.
This is the regexp the test uses to check for that:

function checkObjectToString(s, a) {
  var m = /^{(.*)\}$/(s);
  if (!m)
    return false;  // should begin and end with curly brackets

         etc.
         etc.


Notice that the right brace was escaped, but the left one not.
It looks simply like an oversight when the test was written.

As Roger indicates, the ECMA-262 Edition 3 Final spec is quite clear
that neither '{' nor '}' may appear in a regexp literal unescaped.


However, note that Perl seems to allow '{' and '}' to appear unescaped.
Note, I'm switching between 'p' and 'P' as a sanity check:

perl -e 'if ("{p:1}" =~ /{p/) {print("MATCH!");} else {print("NO MATCH");}'
MATCH!
perl -e 'if ("{p:1}" =~ /{P/) {print("MATCH!");} else {print("NO MATCH");}'
NO MATCH

perl -e 'if ("{p:1}" =~ /{p:1}/) {print("MATCH!");} else {print("NO MATCH");}'
MATCH!
perl -e 'if ("{p:1}" =~ /{P:1}/) {print("MATCH!");} else {print("NO MATCH");}'
NO MATCH


Now, let's try the specific regexp above:
$ perl -e 'if ("{p:1}" =~ /^{(.*)\}$/) {print("MATCH!");}'
MATCH!

Here, without the escape of '}':
$ perl -e 'if ("{p:1}" =~ /^{(.*)}$/) {print("MATCH!");}'
MATCH!



Furthermore, all three of these browsers currently allow it:
Moz/N6/N7, IE6, and N4.7. I will attach an HTML testcase below.

Note we had a similar situation in bug 141078,
"Should JS support octal escape sequences in regexps?"

Here was Brendan's take on that issue: bug 141078 comment 2.
Attached file HTML testcase
In any case, I've gone ahead and added the missing escape to the testcase.
Even though it's "historic" (i.e. lies in the js1_2 directory), I couldn't
find any deliberate reason via bonsai for having the right brace escaped
but the left one not:

http://bonsai.mozilla.org/cvslog.cgi?
file=mozilla/js/tests/js1_2/Objects/toString-001.js
I have modified mozilla/js/tests/ecma_3/RegExp/regress-188206.js
to follow Perl custom regarding braces in regexp patterns.

For reference, from the "perlre" doc on the Web:

----
The following standard quantifiers are recognized:

   *      Match 0 or more times
   +      Match 1 or more times
   ?      Match 1 or 0 times
   {n}    Match exactly n times
   {n,}   Match at least n times
   {n,m}  Match at least n but not more than m times

If a curly bracket occurs in any other context, it is treated
as a regular character.
----


The testcase now tests that braces may appear unescaped in regexp
patterns, even they are not part of a quantifier. This will enforce 
backward compatibility, and compatibility with IE.
Have to reopen this bug. With the new sections, testcase
ecma_3/RegExp/regress-188206.js is failing in Rhino.

These sections use braces, unescaped, as literal characters
in regexp patterns. Even though this is ECMA-incorrect, we
expect no errors, re the compatibility issues raised above -
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Fixed in patch for bug 85721
Depends on: RegExpPerf
Confirming - with the latest patch for bug 85721, the testcase

      mozilla/js/tests/ecma_3/RegExp/regress-188206.js

passes in SpiderMonkey; still failing in Rhino.
Fixed in bug 225926
Status: REOPENED → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
Trageting as resolved against 1.5R5
Target Milestone: --- → 1.5R5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: