Skip to content

Latest commit



426 lines (302 loc) · 14.8 KB


File metadata and controls

426 lines (302 loc) · 14.8 KB

Status of test262 testcases


Test262 provides testcases for various ECMAScript features. It also includes features and behavior beyond E5/E5.1 standard (for instance the tests related to the Intl module and E6).

This document summarizes the currently failing testcases and why they fail. The test run was executed against:

A full list of known bugs is documented in:


This file describes a subset of test cases whose reasons for failure require a longer explanation.

Summary of failure reasons

In addition to unfixed bugs, the following reasons cause some test262 test cases to fail:

  • Anything under intl402 fails as Duktape does not provide the Intl object which is not part of E5/E5.1. Same for es6, which tests for E6 features.
  • Duktape has internal limitations for arrays exceeding 2G or 4G entries (even sparse ones, the limitations related to the indices). These cause some array tests to fail.
  • Duktape does not provice RegExp.prototype.compile which is not part of E5/E5.1.
  • Duktape follows the E5.1 regexp syntax strictly (except for allowing the \$ identity escape). Some things that fail in test cases:
    • invalid backreferences (e.g. /\1/)
    • invalid identity escapes (e.g. /\a/)
    • invalid decimal escapes in character classes (e.g. [\12-\14])
    • special characters appearing literally without escape (e.g. ])
  • Duktape has a conservative limit on the C recursion required to execute regexps. This limit can cause several test cases to fail.
  • When an empty quantifier is being matched with a quantifier such as +, Duktape may now get stuck and match the empty quantified over and over (it should match the quantified a minimum number of times and then continue). To protect against infinite loop, Duktape eventually bails out with a RangeError.
  • Duktape does not support specific locales, which affect e.g. case conversion and locale sensitive string comparison. String.prototype.localeCompare() is the same as an ordinary compare which breaks e.g. ch15/15.5/15.5.4/ "\u006f\u0308" is considered different from "\u00f6" (precomposed).
  • Duktape allows octal syntax. There is a test case which requires that parseInt() should not accept octal syntax; this test case fails.
  • An enumeration corner case test (ch12/12.6/12.6.4/12.6.4-2) currently fails, see test-bug-enum-shadow-nonenumerable.js.
  • There seem to be several bugs in the Date testcases of test262 (see detailed error description).
  • Duktape now allows non-standard function declaration outside Program or FunctionBody top level (such statements are technically not part of E5/E5.1). Unfortunately the semantics for these differ from engine to engine; Duktape uses the V8 semantics of "hoisting" the definition so that the function has only access to the top level variable scope. Although test262 test cases do have non-standard function declarations (outside top level), they seem to be compatible with the V8 semantics and no known issues remain.

Notes on individual errors

Some notes on individual errors. This list is not exhaustive.


Same failure in strict and non-strict modes:

=== annexB/B.RegExp.prototype.compile failed in non-strict mode ===
--- errors ---
TypeError: invalid base reference for property read
        testcase /tmp/test262-T1pW1o.js:2217
        runTestCase /tmp/test262-T1pW1o.js:901
        global /tmp/test262-T1pW1o.js:2059 preventsyield

The E5/E5.1 specification does not include a RegExp.prototype.compile(), so this testcase should actually fail.


Same failure in strict and non-strict modes:

=== ch07/7.8/7.8.5/S7.8.5_A1.4_T1 failed in non-strict mode ===
--- errors ---
SyntaxError: invalid backreference(s) (line 2216)

The test case uses a RegExp of the form /\1/. Based on E5.1 Section this form is invalid (V8 and Rhino allow these broken regexps though):

NOTE An escape sequence of the form followed by a nonzero decimal number n matches the result of the nth set of capturing parentheses (see It is an error if the regular expression has fewer than n capturing parentheses. If the regular expression has n or more capturing parentheses but the nth one is undefined because it has not captured anything, then the backreference always succeeds.

If you comment out the offending regexp, the test case then fails with the following in response to an invalid RegExp /\a/ (again, accepted by V8 and Rhino):

SyntaxError: invalid regexp escape (line 2221)

This RegExp is invalid because "a" is not allowed as an identity escape. E5.1 Section 15.10.1:

IdentityEscape ::
  SourceCharacter but not IdentifierPart

Because "a" belongs to IdentifierPart, it is an invalid identity escape. Because it doesn't match any other alternatives for an AtomEscape either, it should cause a SyntaxError.

Commenting out the /\a/ regexp, the test case finishes.

This test case is a bit dubious anyway, because it asserts that a RegExp source property should have a specific form. E5.1 Section

Let S be a String in the form of a Pattern equivalent to P, in which certain characters are escaped as described below. S may or may not be identical to P or pattern; however, the internal procedure that would result from evaluating S as a Pattern must behave identically to the internal procedure given by the constructed object's [[Match]] internal property.

So, for instance, it would be compliant to have a regexp /x/ with a source property of either x or \u0078 or even (?:\u0078){1}.


Same failure in strict and non-strict modes:

=== ch07/7.8/7.8.5/S7.8.5_A1.4_T2 failed in non-strict mode ===
--- errors ---
Test262 Error: #0031

This is caused by trying to eval the regexp /\1/, which contains a SyntaxError (invalid back-reference, see above).


Enumeration corner case issue, see test-bug-enum-shadow-nonenumerable.js.


=== ch15/15.1/15.1.2/ failed in non-strict mode ===
--- errors ---
Test262 Error: parseInt should no longer accept octal

Duktape parseInt() accepts octal:

duk> parseInt('077')
= 63

This matches Rhino and V8 behavior.


=== ch15/15.10/15.10.2/S15.10.2_A1_T1 failed in non-strict mode ===
--- errors ---
Test262 Error: #4: XML Shallow Parsing with Regular Expression: [^]]*]([^]]+])*]+

First error happens with index 4 into the regexp set, the precise error is:

SyntaxError: invalid regexp character
        RegExp (null) native strict construct preventsyield
        global /tmp/foo.js:2285 preventsyield

The character class [^]] contains an unescaped ] (probably [^\]] was intended, so it gets parsed as a character class [^] followed by a literal, unescaped ] which is a SyntaxError. There are two other instances like this in the test case.


=== ch15/15.10/15.10.2/ failed in non-strict mode ===
--- errors ---
RangeError: regexp executor recursion limit
        exec (null) native strict preventsyield
        global /tmp/test262-yJCwFh.js:2215 preventsyield

Duktape bug: matching /(a*)b\1+/ against "baaaac" first matches an empty string to capture group 1, then matches a "b", and finally ends up matching the empty string with a + quantifier. Duktape doesn't currently always handle empty quantified expressions correctly, so it gets stuck and bails out eventually with a RangeError. See test-regexp-empty-quantified.js.


Same cause as: ch15/15.10/15.10.2/


=== ch15/15.10/15.10.2/ failed in non-strict mode ===
--- errors ---
SyntaxError: invalid regexp control escape
        RegExp (null) native strict construct preventsyield
        global /tmp/test262-heB_na.js:2219 preventsyield

This test case does e.g.:

for (alpha = 0x0410; alpha <= 0x042F; alpha++) {
  str = String.fromCharCode(alpha % 32);
  arr = (new RegExp("\\c" + String.fromCharCode(alpha))).exec(str);
  // ...

The syntax error comes from parsing a RegExp \cX where X is a non-ASCII character (e.g. U+0410 and onwards). This is clearly not allowed by the RegExp syntax in E5.1 Section 15.10.1 (see CharacterEscape and ControlLetter productions).


=== ch15/15.10/15.10.2/ failed in non-strict mode ===
--- errors ---
SyntaxError: decode error
        RegExp (null) native strict construct preventsyield
        global /tmp/test262-4ZVGcj.js:2220 preventsyield

There seems to be a test case error:

var non_ident = "~`!@#$%^&*()-+={[}]|\\:;'<,>./?" + '"';
var k = -1;
do {
   print("\\" + non_ident[k], "g")
   arr = new RegExp("\\" + non_ident[k], "g").exec(non_ident);
} while ((arr !== null) && (arr[0] === non_ident[k]))

The loop works correctly until k points outside the non_ident array. The loop then tries to create a regexp with:

new RegExp("\\" + undefined, "g");

The RegExp input will be \undefined which contains an invalid Unicode escape, causing the SyntaxError from Duktape. There is no valid way of parsing \u in a regexp. Note that \u is not allowed as an identity escape (IdentityEscape explicitly rejects IdentifierPart characters), and there are no other rules allowing it either.


=== ch15/15.10/15.10.2/ failed in non-strict mode ===
--- errors ---
SyntaxError: invalid decimal escape (line 2215)

The SyntaxError is caused by:

__executed = /[\d][\12-\14]{1,}[^\d]/.exec("line1\n\n\n\n\nline2");

Here, a \12 DecimalEscape occurs inside a character class. The DecimalEscape evaluates to the integer 12 (see E5.1 Section, step 3). Then, the ClassEscape throws a SyntaxError; see E5.1 Section steps 1-2:

1. Evaluate DecimalEscape to obtain an EscapeValue E.

2. If E is not a character then throw a SyntaxError exception.


A SyntaxError occurs with the RegExp:

__executed = /\B\[^z]{4}\B/.test("devil arise\tforzzx\nevils");

The \[ is accepted as an identity escape, which then leads to SyntaxError because none of ^, ], {, or } are accepted unescaped by E5.1 (see PatternCharacter production).

The point of the testcase is probably to test that \[ is not evaluated as [. If the escape is removed, the RegExp matches with the result "il a" with both Duktape and Rhino. This causes a test case failure, the test case is expected not to match.

If the invalid characters are escaped, the test case passes:

__executed = /\B\[\^z\]\{4\}\B/.test("devil arise\tforzzx\nevils");


=== ch15/15.4/15.4.4/ failed in non-strict mode ===
--- errors ---
Test262 Error: #1: var obj = {}; obj.slice = Array.prototype.slice; obj[4294967294] = "x"; obj.length = 4294967295; var arr = obj.slice(4294967294,4294967295); arr.length === 1. Actual: 0

This bug is probably caused by C typing related to array length handling. Arrays over 2G elements long will probably have such issues. There are several similar failing test cases, e.g.:

  • ch15/15.4/15.4.4/
  • ch15/15.4/15.4.4/
  • ch15/15.4/15.4.4/
  • ch15/15.4/15.4.4/
  • ch15/15.4/15.4.4/

Fortunately these don't have much real world relevance.


=== ch15/15.5/15.5.4/ failed in non-strict mode ===
--- errors ---
Test262 Error: #1: __instance = new Date(0); __instance.indexOf = String.prototype.indexOf;  (__instance.getTimezoneOffset()>0 ? __instance.indexOf('31') : __instance.indexOf('01')) === 8. Actual: 5

The test case relies on the toString() coercion of a Date instance. For instance, Rhino formats the __instance as:

Thu Jan 01 1970 02:00:00 GMT+0200 (EET)

The index for "01" here is 8. Note that this format is locale and platform specific so the test case is not reliable. Duktape uses ISO 8601 also for toString():

1970-01-01 02:00:00.000+02:00

Here the index for "01" is 5, which causes a test case failure.


These tests fail with:

=== ch15/15.9/15.9.3/S15.9.3.1_A5_T1 failed in non-strict mode ===
--- errors ---
Test262 Error: #1: Incorrect value of Date

There seem to be incorrect comparison values for the Dates. For example, in T6:

if (-2208960000001 !== new Date(1899, 11, 31, 23, 59, 59, 999).valueOf()) {
  $FAIL("#1: Incorrect value of Date");

The date expression yields -2208996000001 in both Rhino and V8, so the test case is probably incorrect (there is a missing 9 digit and extra 0 digit)). There are similar issues in test 2 and 3 too. Test 4 also seems incorrect:

if (28799999 !== new Date(1969, 11, 31, 23, 59, 59, 999).valueOf()) {
  $FAIL("#4: Incorrect value of Date");

Because Jan 1, 1970 is the "zero point", all dates before that will have negative time values, so the test case is obviously incorrect. Rhino and V8 agree, returning -7200001 for the expression.

All of these test cases also fail with Rhino, and the errors seem to be in the comparison values of the test case.