482298 - (es5strict) Implement ES5 strict mode

Status: REOPENED

(Core :: JavaScript Engine, defect)

Description

[Jim Blandy :jimb]

Strict Mode is described in section 10.1.1 of the ECMAScript draft ("Sunnyvale" version, March 2).

Comment 1

[Brendan Eich [:brendan]]

Igor reminded me that we have code generation optimizations to nullify updating const-declared bindings and certain JSPROP_READONLY built-ins (the callee named by the function's identifier as an expression, in the body of a named function expression where there is no shadowing arg, var, or let -- and no eval which might make a deletable, shadowing var).

We already have a strict option to enable warnings (which can be errors if you use the separate werror option). So these emitter optimizations are bugs in that they should use the JSREPORT_STRICT, etc., reporting machinery, never mind ES5.

But implementing ES5 strict mode will shake all this up. I would rather we move our existing strict option to agree with ES5 strict mode, except that it warns still (people may count on this in ways that would be hard to change if we suddenly made our strict option imply the werror option).

Alternative: change werror to be the default, allow it to be cleared or toggled off.

In any case we should hope to align the case analysis for our strict option and ES5's strict mode.

/be

Comment 2

[Brendan Eich [:brendan]]

This bug needs an owner ;-).

/be

Comment 3

[Jim Blandy :jimb]

Yes indeed.

Comment 4

[Jim Blandy :jimb]

Been working on bug 464750; I'll be better about timesharing and give this one some attention, too.

Comment 5

[Brendan Eich [:brendan]]

http://groups.google.com/group/mozilla.dev.tech.js-engine/browse_frm/thread/e5a77defe4172436#

I just commented.

/be

Comment 6

[Jim Blandy :jimb]

Jason Orendorff and I talked briefly on IRC about reconciling ES5 strict mode and the JSAPI's JSOPTION_STRICT.

The most direct approach would be to simply equate these two by having existing JSOPTION_STRICT checks also consult the currently running script: while the context's top active frame, if any, is in ES5 strict mode code, the context behaves as if JSOPTION_STRICT were set.  While easy to describe, this doesn't seem useful: many JSAPI operations perform JSOPTION_STRICT tests, and if the call stack looks like:

  C++ code -> strict mode JavaScript -> C++ JSNative -> some JSAPI fun

it seems wrong to have that JavaScript frame affect what the C++ JSNative is permitted to do.  One can draw an analogy with a pure JavaScript case: when a strict mode JS function calls a non-strict JS function, the latter's behavior is unaffected.  The same principle should hold if the callee is implemented in C++.

The approach we arrived is to change only those sites that test JSOPTION_STRICT that are clearly performing an operation on behalf of a specific JSScript to also consult that JSScript's strict mode flag.

Comment 7

[Lars Gunther]

When I enable "use strict" in about:config for Minefield, it will not run the ES5 test suite, downloaded from http://es5conform.codeplex.com/ (also available at http://kangax.github.com/es5-testsuite/).

It chokes on 12.2.1-11 "arguments as var identifier in eval code is allowed". Is that a known bug or am I doing something wrong? Should I file it? 

(I am using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100511 Minefield/3.7a5pre)

(And yes, I have searched Bugzilla as good as thouroughly as I can, but sometimes bugs are filed with very cryptic names for us non-experts.)

Comment 8

[Lars Gunther]

Sorry for any confusion. It should be when I enable strict error logging in about:config, not when I enable "use strict"...

Comment 9

[Jim Blandy :jimb]

Unfortunately, we have two separate meanings of "strict" in play here: the long-standing Mozilla "strict" option, which I believe is what you're enabling with about:config, and the new "use strict" mode defined in EcmaScript 5. We're expanding the former to keep it a superset of the latter, with the exception that 'with' statements, forbidden in ES5 strict mode, are fine under the Mozilla "strict" option.

There's no reason that the ES5 test suite would necessary conform with Mozilla's "strict" option, so I don't think there's a bug to be filed.

Comment 10

[Brendan Eich [:brendan]]

Lars: do you also set the javascript.options.werror boolean option to true via about:config? If not, then you shouldn't be getting any errors (which turn into exceptions), only warnings in the console.

/be

Comment 11

[Lars Gunther]

If I do that, the test will run, but I get a gazillion errors in the console. And a blank page as the end result.

Most errors are "Function testcase does not always return a value" which seem harmless. But I also get a few "ES5harness is undefined".

Tried today in Mozilla/5.0 (X11; Linux i686; rv:2.0b2pre) Gecko/20100720 Minefield/4.0b2pre

Comment 12

[Jim Blandy :jimb]

So, Lars, just to confirm: if you turn on javascript.options.strict, and not javascript.options.werror, and the ES5 test suite fails to execute correctly, but runs correctly with javascript.options.strict turned off, then that's a bug; if you could file it and CC me, that would be great.

Turning on javascript.options.strict alone should not affect the *execution* of any code, just the warnings it produces. Turning on werror tells the system to treat those warnings as JS errors, which will certainly change the execution of programs that would otherwise run fine.

Comment 13

[Jim Blandy :jimb]

(I expanded the set of conditions javascript.options.strict complains about, so that we could have the simple rule that the strict option was pickier than ES5 "use strict"; it's confusing enough having them not be the same thing. But I may have inadvertently changed the behavior aside from warnings; that's something I need to know about and fix.)

Comment 14

[Brendan Eich [:brendan]]

Not sure we need it now due to greater strictness, but does anyone know of a bug on file asking for warning limits to prevent (unintended, in all likelihood) DoS (self-)attacks?

/be

Comment 15

[Boris Zbarsky [:bzbarsky]]

Lars filed bug 580932 per comment 12.

Comment 16

[Scott Sims]

Will this bug be fixed before the release of Firefox 4?

Comment 17

[Brendan Eich [:brendan]]

(In reply to comment #16)
> Will this bug be fixed before the release of Firefox 4?

Count on it.

/be

Comment 19

[David Bruant]

Even if still a bit incomplete (especially the eval part), there is some doc that has been written :
https://developer.mozilla.org/en/JavaScript/Strict_mode
Maybe that the "dev-doc-needed" keyword may be errased from the white board. I was the main author of the article. Feel free to contact me if there is something wrong or inaccurate or even forgotten.
On the other hand, I'd need some help to document the last point of this part https://developer.mozilla.org/en/JavaScript/Strict_mode#Differences_in_functions (the point about something changed in how arguments are bound to the actual named arguments)

Comment 20

[Jeff Walden [:Waldo]]

https://developer.mozilla.org/en/JavaScript/Strict_mode (mentioned earlier) has long been updated to comprehensively document strict mode, so I think this is documented.

Comment 21

[Jim Blandy :jimb]

Our strict mode support is pretty much done, as far as I know.

Comment 22

[Jason Orendorff [:jorendorff]]

Still one item: bug 605515.