208586 - Minimal no-extensions ECMA-2 Edition 3 JS engine configuration

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Brendan Eich [:brendan]]

This has to work both for the static (compile-time) configuration selected via
JS_VERSION and jsconfig.h, and the runtime per-context version.  Patch in a
minute that's almost right (need to split JS_HAS_MORE_PERL_FUN up, check others,
to avoid excess baggage).

/be

Comment 1

[Brendan Eich [:brendan]]

Attachment: add ECMAv3 compile- and runtime version support

Please test on trunk builds.  I've tested using the testsuite, excluding js1_1
through js1_5 along with the liveconnect (lc2 lc3) tests.

/be

Comment 2

[Brendan Eich [:brendan]]

Attachment: better patch

This rips out the "not yet implemented" errors configured for certain
Perl-inspired Array.prototype and String.prototype methods, consolidating #if
JS_HAS_... tests around entire hunks of native methods and their corresponding
JSFunctionSpec initializers.

This patch also adds a JS_HAS_STR_HTML_HELPERS jsconfig.h macro and turns it
off for the new pure-ECMA-262-Edition-3 mode, on for all others.

I think I'm done.  What I could use is more testing help (I've rebuilt and
retested the JS shell enough to be satisfied), and a thumbs-up from anyone on
the CC: list who cares.

/be

Comment 3

[Mike Shaver (:shaver emeritus)]

Comment on attachment 125154 [details] [diff] [review]
better patch

That looks fine.

I can't remember from The Past, and I'm too lazy to look: do we already
condition the 09-as-9 octal parsing extension on ECMAism?  Probably not, in
which case it seems like we should carve it out for this mode as well.

Comment 4

[Brendan Eich [:brendan]]

Checked in.  Yeah, ECMA-262 Edition 3 kicked octal numeric literals and string
character escape sequences out to Appendix B, which is non-normative.  I'd like
to defer configuring out the jsscan.c and other code that deals with octals,
until someone whines about footprint or standards purity.  I don't expect more
than a few hundred bytes' code space savings.

Thanks for pointing it out.  A bug could be filed, or perhaps this comment is
enough for now (maybe forever).

/be

Comment 5

[Brendan Eich [:brendan]]

BTW, I can't find a lexical production for OctalDigit in ECMA-262 Edition 3.

Cc'ing waldemar in case that spec bug still needs to be fixed, and in case he
has an opinion on the propriety of including octal literal support in an
ECMA-3-only configuration.

/be

Comment 6

[Waldemar Horwat]

Oops, I didn't see that ECMA Edition 3 has no OctalDigit production.  It's
fairly obvious what it should be.

Whether the no-extensions engine configuration should support Appendix B depends
on the purpose of said engine.  If it's mainly to test programs for standards
purity, then that engine should not support octals; if it's just to cut down the
size of the engine, then it doesn't matter.

Comment 7

[Brendan Eich [:brendan]]

The purpose, in my view, of the JS_VERSION == JS_VERSION_ECMA_3 support, is to
minimize footprint.  ECMA purity for test coverage is secondary, at best, and
not easily done with today's testsuite (some ECMA tests may be mixed into
js1_[1-5]/* regression tests, we think).

/be

Comment 8

[Waldemar Horwat]

I added OctalDigit to the ECMAScript Edition 3 errata page:
http://www.mozilla.org/js/language/E262-3-errata.html

Comment 9

[Brendan Eich [:brendan]]

Forgot to include the obvious patch for jsarray.c, which I have just checked in.

/be

Comment 10

[Phil Schwartau]

Reopening bug, because I can't build the minimal JS shell on WinNT4.0.
I am using Makefile.ref to build, after editing jsconfig.h as follows:

#ifndef JS_VERSION
#define JS_VERSION 149  <------------ putting 149 here instead of 150
#endif

I then get an error on the linking part of the build:

                     etc.
                     etc.

Creating library WINNT4.0_DBG.OBJ/js32.lib and object WINNT4.0_DBG.OBJ/js32.exp
jsxdrapi.obj : error LNK2001: unresolved external symbol _js_XDRObject
jsxdrapi.obj : error LNK2001: unresolved external symbol _js_XDRScript
WINNT4.0_DBG.OBJ/js32.dll : fatal error LNK1120: 2 unresolved externals
make[1]: *** [WINNT4.0_DBG.OBJ/js32.dll] Error 96
make[1]: Leaving directory `//d/JS_EXP/mozilla/js/src'
make: *** [all] Error 2


I get no such errors on Linux when I perform the same procedure.

Comment 11

[Brendan Eich [:brendan]]

Fixed jsxdrapi.c by including jsconfig.h ASAP (right after jsstddef.h), then
using #if JS_HAS_XDR...#endif around the rest of the file below that point.

/be

Comment 12

[Phil Schwartau]

Thanks; now I can build the minimal engine on Windows. Here are the results
against the JS testsuite. First, I prepared a list of the current known test
failures on WinNT4.0, in order to skip them all:

ecma_2/String/match-002.js
ecma_3/RegExp/15.10.2-1.js
ecma_3/RegExp/perlstress-001.js
ecma_3/RegExp/perlstress-002.js
ecma_3/RegExp/regress-123437.js
ecma_3/RegExp/regress-165353.js
ecma_3/RegExp/regress-169497.js
ecma_3/RegExp/regress-169534.js
ecma_3/RegExp/regress-187133.js
ecma_3/RegExp/regress-188206.js
ecma_3/RegExp/regress-191479.js
ecma_3/RegExp/regress-202564.js
ecma_3/RegExp/regress-209067.js
ecma_3/RegExp/regress-31316.js
ecma_3/RegExp/regress-85721.js
ecma_3/RegExp/regress-87231.js
js1_2/regexp/vertical_bar.js
js1_5/Array/regress-101964.js
js1_5/Regress/regress-152646.js
js1_5/Regress/regress-192414.js
js1_5/Regress/regress-192465.js
js1_5/Regress/regress-96128-n.js


Then I ran the test driver with option -L lc2 lc3 KNOWN_FAILURES.list,
to skip the lc2, lc3 directories (as always), and the above list. Here
are the test failures I got, reflecting the lack of non-ECMA features
in the minimal JS engine (which is what we expect):

ecma_3/Exceptions/catchguard-001.js
ecma_3/Exceptions/catchguard-002.js
ecma_3/Exceptions/catchguard-003.js
js1_3/Script/script-001.js
js1_5/Exceptions/regress-50447.js
js1_5/GetSet/getset-001.js
js1_5/GetSet/getset-002.js
js1_5/GetSet/getset-003.js
js1_5/GetSet/getset-004.js
js1_5/GetSet/getset-005.js
js1_5/GetSet/getset-006.js
js1_5/Object/regress-90596-001.js
js1_5/Object/regress-90596-002.js
js1_5/Object/regress-96284-001.js
js1_5/Object/regress-96284-002.js
js1_5/Regress/regress-104077.js
js1_5/Regress/regress-44009.js
js1_5/Regress/regress-68498-003.js
js1_5/Regress/regress-76054.js
js1_5/Scope/scope-001.js


As Brendan pointed out to me, the three catch guard tests at the top
shouldn never have been put in an "ecma" test directory to begin with.
I will move them to the js1_5 directory.

I will also dig deeper and see if every test we would expect to fail
in the minimal engine (i.e. every test that uses non-ECMA syntax)
is appearing on this list.

In an ideal world, the testsuite would be cleanly divided between tests
that use non-EMCA extensions (in the js* directories) and the tests that
do not (in the ecma* directories). Unfortunately, this is not the case,
which is why the new list does not simply consist of all the js* tests.

Comment 13

[Phil Schwartau]

I have just moved all catch guard tests from the ecma_3/Exceptions
directory to the js1_5/Exceptions directory, since this is non-ECMA syntax.

Comment 14

[Bob Clary [:bc] (inactive)]

note to self: 1.8 opt browser peach 20060803 build timed out on js1_5/GetSet/getset-001.js but not prune. 

Comment 15

[Bob Clary [:bc] (inactive)]

note to self: js1_5/GetSet/getset-001.js timed out on 1.9 windows debug but not on any other. heisentimeouts.

Comment 16

[Bob Clary [:bc] (inactive)]

(In reply to comment #15)
1.9a1_2006080806