Name Description Size Coverage
browser.js 0 -
lastIndexOf-ToNumber-when-searchStr-larger-than-string.js 615 -
make-normalize-generateddata-input.py Usage: make-normalize-generateddata-input.py PATH_TO_MOZILLA_CENTRAL This script generates test input data for String.prototype.normalize from intl/icu/source/data/unidata/NormalizationTest.txt to js/src/tests/non262/String/normalize-generateddata-input.js 2929 -
match-001.js File Name: String/match-001.js ECMA Section: 15.6.4.9 Description: Based on ECMA 2 Draft 7 February 1999 Author: christine@netscape.com Date: 19 February 1999 3385 -
match-002.js File Name: String/match-002.js ECMA Section: 15.6.4.9 Description: Based on ECMA 2 Draft 7 February 1999 Author: christine@netscape.com Date: 19 February 1999 4750 -
match-003.js File Name: String/match-003.js ECMA Section: 15.6.4.9 Description: Based on ECMA 2 Draft 7 February 1999 Author: christine@netscape.com Date: 19 February 1999 3639 -
match-004.js File Name: String/match-004.js ECMA Section: 15.6.4.9 Description: Based on ECMA 2 Draft 7 February 1999 Author: christine@netscape.com Date: 19 February 1999 4410 -
normalize-generateddata-input.js created from NormalizationTest-17.0.0.txt 2532052 -
normalize-generateddata-part0.js 518 -
normalize-generateddata-part1-not-listed.js not listed in Part 1 1164 -
normalize-generateddata-part1.js 523 -
normalize-generateddata-part2.js 518 -
normalize-generateddata-part3.js 518 -
regress-83293.js Creation Date: 30 May 2001 Correction Date: 14 Aug 2001 SUMMARY: Regression test for bugs 83293, 103351 See http://bugzilla.mozilla.org/show_bug.cgi?id=83293 http://bugzilla.mozilla.org/show_bug.cgi?id=103351 http://bugzilla.mozilla.org/show_bug.cgi?id=92942 ******************** CORRECTION !!! ***************************** When I originally wrote this test, I thought this was true: str.replace(strA, strB) == str.replace(new RegExp(strA),strB). See ECMA-262 Final Draft, 15.5.4.11 String.prototype.replace However, in http://bugzilla.mozilla.org/show_bug.cgi?id=83293 Jim Ley points out the ECMA-262 Final Edition changed on this. String.prototype.replace (searchValue, replaceValue), if provided a searchValue that is not a RegExp, is NO LONGER to replace it with new RegExp(searchValue) but rather: String(searchValue) This puts the replace() method at variance with search() and match(), which continue to follow the RegExp conversion of the Final Draft. It also makes most of this testcase, as originally written, invalid. ********************************************************************* 6154 -
regress-104375.js Date: 12 October 2001 SUMMARY: Regression test for string.replace bug 104375 See http://bugzilla.mozilla.org/show_bug.cgi?id=104375 1748 -
regress-107771.js Date: 31 October 2001 SUMMARY: Regression test for bug 107771 See http://bugzilla.mozilla.org/show_bug.cgi?id=107771 The bug: Section 1 passed, but Sections 2-5 all failed with |actual| == 12 1784 -
regress-112626.js 591 -
regress-179068.js Date: 09 November 2002 SUMMARY: Test that interpreter can handle string literals exceeding 64K See http://bugzilla.mozilla.org/show_bug.cgi?id=179068 Test that the interpreter can handle string literals exceeding 64K limit. For that the script passes to eval() "str ='LONG_STRING_LITERAL';" where LONG_STRING_LITERAL is a string with 200K chars. Igor Bukanov explains the technique used below: > Philip Schwartau wrote: >... > Here is the heart of the testcase: > > // Generate 200K long string > var long_str = duplicate(LONG_STR_SEED, N); > var str = ""; > eval("str='".concat(long_str, "';")); > var test_is_ok = (str.length == LONG_STR_SEED.length * N); > > > The testcase creates two identical strings, |long_str| and |str|. It > uses eval() simply to assign the value of |long_str| to |str|. Why is > it necessary to have the variable |str|, then? Why not just create > |long_str| and test it? Wouldn't this be enough: > > // Generate 200K long string > var long_str = duplicate(LONG_STR_SEED, N); > var test_is_ok = (long_str.length == LONG_STR_SEED.length * N); > > Or do we specifically need to test eval() to exercise the interpreter? The reason for eval is to test string literals like in 'a string literal with 100 000 characters...', Rhino deals fine with strings generated at run time where lengths > 64K. Without eval it would be necessary to have a test file excedding 64K which is not that polite for CVS and then a special treatment for the compiled mode in Rhino should be added. > > If so, is it important to use the concat() method in the assignment, as > you have done: |eval("str='".concat(long_str, "';"))|, or can we simply > do |eval("str = long_str;")| ? The concat is a replacement for eval("str='"+long_str+"';"), but as long_str is huge, this leads to constructing first a new string via "str='"+long_str and then another one via ("str='"+long_str) + "';" which takes time under JDK 1.1 on a something like StrongArm 200MHz. Calling concat makes less copies, that is why it is used in the duplicate function and this is faster then doing recursion like in the test case to test that 64K different string literals can be handled. 3844 -
regress-189898.js Date: 21 January 2003 SUMMARY: Regression test for bug 189898 See http://bugzilla.mozilla.org/show_bug.cgi?id=189898 2456 -
regress-304376.js 746 -
regress-305064.js List from ES 3.1 Recommendation for String.trim (bug 305064) * 4507 -
regress-313567.js 659 -
regress-392378.js 1599 -
replace-rope-empty.js 910 -
ropes.js 1713 -
shell.js --- defines: [runNormalizeTest] allow_unused: True --- 2618 -
string-code-point-upper-lower-mapping.js Generated by make_unicode.py DO NOT MODIFY 84979 -
string-object-length.js BEGIN TEST * ************ 391 -
string-space-trim.js Generated by make_unicode.py DO NOT MODIFY 1433 -
string-upper-lower-mapping.js Generated by make_unicode.py DO NOT MODIFY 3234010 -
utf8-encode.js 4282 -
well-formed.js 3921 -