370585 - JavaScript Tests - segregate some non-standard tests

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement)

Description

[Bob Clary [:bc] (inactive)]

This bug is to be used to track remaining work to be accomplished with regard to segregating tests which depend upon SpiderMonkey only extensions to the the ECMA standards. Please file remaining issues as separate bugs and block this one. Thanks.

Comment 1

[Lars T Hansen]

ecma/array/15.4.4.3-1.js uses "unescape" which is in JS but not in ES.

Comment 2

[Bob Clary [:bc] (inactive)]

Attachment: list of decompilation tests to be moved

This list contains tests which contain compareSource functin calls but which are not already in a /decompilation/ subsuite.

Comment 3

[Bob Clary [:bc] (inactive)]

Attachment: gzipped cvs log...

tests in comment 2 have been moved.

Comment 4

[Bob Clary [:bc] (inactive)]

(In reply to comment #1)
> ecma/array/15.4.4.3-1.js uses "unescape" which is in JS but not in ES.
> 

/cvsroot/mozilla/js/tests/ecma/Array/15.4.4.3-1.js,v  <--  15.4.4.3-1.js
new revision: 1.6; previous revision: 1.5

Comment 5

[Lars T Hansen]

ecma_2/RegExp/regress-188206.js: sections 7 and 8 do not test the regexp package, these are unterminated multiline comments that are caught by the program lexer.

Comment 6

[Lars T Hansen]

General comment about the regular expression tests: there are plenty of tests for variations on octal numbers / escape sequences.  E262-3 does not support octal.  E262-4 will support octal, though probably not with the restrictions and fallback behavior that FF uses (eg, \097 is interpreted as decimal 97 by FF).

Comment 7

[Lars T Hansen]

ecma_2/RegExp/regress-188206.js: sections 13 through 27 do not follow the ECMA spec (any edition); there is a comment in the file that provides the full story.  Should be factored out.

Comment 8

[Lars T Hansen]

(I'm sorry, regress-188206.js is of course in ecma_3/RegExp.)

Comment 9

[Lars T Hansen]

ecma_3/RegExp/regress-220367-002.js: this entire test is nonconformant with E262-3, which does not provide the RegExp.$n variables, nor are these slated for inclusion in E262-4.

Comment 10

[Lars T Hansen]

ecma_3/RegExp/regress-228087.js: all sections except 5, 11, and 14 are illegal according to E262-3 / E262-4 draft.

Comment 11

[Lars T Hansen]

ecma_3/RegExp/regress-85721.js: this is a performance test.  It probably does not belong here.

Comment 12

[Lars T Hansen]

ecma_3/RegExp/octal-001.js: section 1 contains the subpattern "\240".  E262-3 15.10.2.9 bullet 7 states that this is a syntax error, so this test is illegal.

Comment 13

[Lars T Hansen]

ecma_3/RegExp/regress-311414.js: contains a call to the nonstandard global function "gc".  The test itself seems valuable, but it's not clear how it can be both reliable and portable.

Comment 14

[Lars T Hansen]

ecma_3/RegExp/regress-327170.js: uses a method "compile" on the regular expression object, this method is not in E262-3 nor in the 4th Ed draft.

Comment 15

[Lars T Hansen]

ecma_3/RegExp/regress-103087.js: this test references RegExp.lastMatch, RegExp.leftContext, and RegExp.rightContext, none of which are in ECMAScript.

Comment 16

[Lars T Hansen]

ecma/String/15.5.4.8-2.js: The test containing these lines:

  var TEST_STRING = "thisundefinedisundefinedaundefinedstringundefinedobject";

  var EXPECT_STRING = new Array( "this", "is", "a", "string", "object" );

is invalid; E262-3 15.5.4.14 step 8 states clearly that a separator with a value of "undefined" is handled specially, and FF2 conforms to the spec, not to this test.

Comment 17

[Bob Clary [:bc] (inactive)]

Date.prototype.toLocaleFormat is tested in js1_5/Date/toLocaleFormat.js and is non-standard.

Comment 18

[Bob Clary [:bc] (inactive)]

comment 17 fixed.
Checking in extensions/toLocaleFormat-01.js;
/cvsroot/mozilla/js/tests/js1_5/extensions/toLocaleFormat-01.js,v  <--  toLocaleFormat-01.js
initial revision: 1.1
done
Removing Date/toLocaleFormat.js;
/cvsroot/mozilla/js/tests/js1_5/Date/toLocaleFormat.js,v  <--  toLocaleFormat.js
new revision: delete; previous revision: 1.5
done

Comment 19

[Bob Clary [:bc] (inactive)]

Checking in extensions/regress-188206-01.js;
/cvsroot/mozilla/js/tests/ecma_3/extensions/regress-188206-01.js,v  <--  regress-188206-01.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/js/tests/ecma_3/extensions/regress-188206-02.js,v
done
Checking in extensions/regress-188206-02.js;
/cvsroot/mozilla/js/tests/ecma_3/extensions/regress-188206-02.js,v  <--  regress-188206-02.js
initial revision: 1.1
done
Checking in RegExp/regress-188206.js;
/cvsroot/mozilla/js/tests/ecma_3/RegExp/regress-188206.js,v  <--  regress-188206.js
new revision: 1.8; previous revision: 1.7
done

Comment 20

[Bob Clary [:bc] (inactive)]

(In reply to comment #9)
> ecma_3/RegExp/regress-220367-002.js: this entire test is nonconformant with
> E262-3, which does not provide the RegExp.$n variables, nor are these slated
> for inclusion in E262-4.
> 

Removing RegExp/regress-220367-002.js;
/cvsroot/mozilla/js/tests/ecma_3/RegExp/regress-220367-002.js,v  <--  regress-220367-002.js
new revision: delete; previous revision: 1.5
done
RCS file: /cvsroot/mozilla/js/tests/ecma_3/extensions/regress-220367-002.js,v
done
Checking in extensions/regress-220367-002.js;
/cvsroot/mozilla/js/tests/ecma_3/extensions/regress-220367-002.js,v  <--  regress-220367-002.js
initial revision: 1.1
done

Comment 21

[Bob Clary [:bc] (inactive)]

(In reply to comment #10)
> ecma_3/RegExp/regress-228087.js: all sections except 5, 11, and 14 are illegal
> according to E262-3 / E262-4 draft.
> 

Funny if es4 doesn't support these since both IE and Firefox pass them. :-)

Checking in extensions/regress-228087.js;
/cvsroot/mozilla/js/tests/ecma_3/extensions/regress-228087.js,v  <--  regress-228087.js
initial revision: 1.1
done
Removing RegExp/regress-228087.js;
/cvsroot/mozilla/js/tests/ecma_3/RegExp/regress-228087.js,v  <--  regress-228087.js
new revision: delete; previous revision: 1.9
done

(In reply to comment #11)
> ecma_3/RegExp/regress-85721.js: this is a performance test.  It probably does
> not belong here.
> 

I'll leave it for now, but it raises the question of placing all performance related tests into a perf or performance subsuite.

(In reply to comment #12)
> ecma_3/RegExp/octal-001.js: section 1 contains the subpattern "\240".  E262-3
> 15.10.2.9 bullet 7 states that this is a syntax error, so this test is illegal.
> 

Handle as part of bug 381062

(In reply to comment #13)
> ecma_3/RegExp/regress-311414.js: contains a call to the nonstandard global
> function "gc".  The test itself seems valuable, but it's not clear how it can
> be both reliable and portable.
> 

In the shell, gc is a native function but in the browser it is defined in a way that will at least execute in all browsers. I'll leave it for now.


(In reply to comment #14)
> ecma_3/RegExp/regress-327170.js: uses a method "compile" on the regular
> expression object, this method is not in E262-3 nor in the 4th Ed draft.
> 
Checking in extensions/regress-327170.js;
/cvsroot/mozilla/js/tests/ecma_3/extensions/regress-327170.js,v  <--  regress-327170.js
initial revision: 1.1
done
Removing RegExp/regress-327170.js;
/cvsroot/mozilla/js/tests/ecma_3/RegExp/regress-327170.js,v  <--  regress-327170.js
new revision: delete; previous revision: 1.2
done

(In reply to comment #15)
> ecma_3/RegExp/regress-103087.js: this test references RegExp.lastMatch,
> RegExp.leftContext, and RegExp.rightContext, none of which are in ECMAScript.
> 

Checking in extensions/regress-103087.js;
/cvsroot/mozilla/js/tests/ecma_3/extensions/regress-103087.js,v  <--  regress-103087.js
initial revision: 1.1
done
Removing RegExp/regress-103087.js;
/cvsroot/mozilla/js/tests/ecma_3/RegExp/regress-103087.js,v  <--  regress-103087.js
new revision: delete; previous revision: 1.9
done

Comment 22

[Bob Clary [:bc] (inactive)]

(In reply to comment #16)
> ecma/String/15.5.4.8-2.js: The test containing these lines:
> 
>   var TEST_STRING = "thisundefinedisundefinedaundefinedstringundefinedobject";
> 
>   var EXPECT_STRING = new Array( "this", "is", "a", "string", "object" );
> 
> is invalid; E262-3 15.5.4.14 step 8 states clearly that a separator with a
> value of "undefined" is handled specially, and FF2 conforms to the spec, not to
> this test.
> 

Firefox 1.8.1 and trunk currently passes the test as is, so I'm not sure what you mean by "FF2 conforms". But looking at the spec, it does seem that 

s.split(undefined) should return [s] but both Firefox and IE pass the test. I'll let brendan or crowder comment.

Comment 23

[Bob Clary [:bc] (inactive)]

I'm marking this bug fixed. Any other issues should be filed as separate bugs blocking bug 399396. 

Lars, I would like to offer my thanks for your help in identifying these tests. It is _deeply_ appreciated.

Comment 24

[Bob Clary [:bc] (inactive)]

oops, missed this.

Checking in spidermonkey-extensions-n.tests;
/cvsroot/mozilla/js/tests/spidermonkey-extensions-n.tests,v  <--  spidermonkey-extensions-n.tests
new revision: 1.6; previous revision: 1.5
done

Comment 25

[Bob Clary [:bc] (inactive)]

I missed that regress-228087.js rrequired some functions from ecma_3/RegExp/shell.js. 

Checking in shell.js;
/cvsroot/mozilla/js/tests/ecma_3/extensions/shell.js,v  <--  shell.js
new revision: 1.3; previous revision: 1.2
done