Closed
Bug 190685
Opened 22 years ago
Closed 21 years ago
Unexpected SyntaxError for /^{(.*)\}$/
Categories
(Rhino Graveyard :: Core, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
1.5R5
People
(Reporter: user, Assigned: rogerl)
References
()
Details
Attachments
(3 files)
1.25 KB,
text/html
|
Details | |
4.26 KB,
text/html
|
Details | |
4.41 KB,
patch
|
Details | Diff | Splinter Review |
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: /{\}/
Reporter | ||
Comment 2•22 years ago
|
||
Although the Ecma standard does not allow standalong {, but SM and js in MSIE allows it.
Assignee | ||
Comment 3•22 years ago
|
||
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
Assignee | ||
Comment 4•22 years ago
|
||
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 ?
Comment 5•22 years ago
|
||
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.
Comment 6•22 years ago
|
||
Comment 7•22 years ago
|
||
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
Comment 8•22 years ago
|
||
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.
Comment 9•22 years ago
|
||
Comment 10•22 years ago
|
||
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 → ---
Comment 12•21 years ago
|
||
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.
Comment 13•21 years ago
|
||
Comment 14•21 years ago
|
||
Fixed in bug 225926
Status: REOPENED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•