-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compatibility with Hardened JavaScript #4088
base: main
Are you sure you want to change the base?
Conversation
Using |
145913a also uses |
I believe it’s necessary because the things it’s shadowing are accessors in a locked-down realm. |
@anba, thanks for the review.
I wanted an indication of the Date constructor changes made for Hardened JavaScript and chose
Setting |
The exact value doesn't matter to me, it's just important for me that there's no confusion about the milliseconds value which is passed to
I'd prefer to either:
When only |
@anba – I've changed For |
This PR proposes changes to existing test262 tests to allow them to pass under Hardened JavaScript (see Secure ECMAScript proposal and Hardened JavaScript). Moddable uses Hardened JavaScript for JavaScript runtimes on resource constrained embedded devices, including those targeted by ECMA-419.
The changes fall into four groups:
new Date()
withnew Date(1970)
. Scripts running inside aCompartment
cannot retrieve the current time, sonew Date()
throws butnew Date(1970)
succeeds. Very few tests need the current time, but instead simply need aDate
instance.Object.defineProperty
instead of setting existing built-in properties directly, such astoString
andtoValue
. In Hardened JavaScript, prototypes of built-in objects are frozen. Consequently, setting properties of an instance that exist on the prototype throw (Hardened JavaScript is always in strict mode).Math.random()
. Scripts running inside aCompartment
cannot generate random numbers. One test identified so far usesMath.random()
in a way that can easily be replaced with a counter.This test passes, but only because
new Date()
fails by throwing aTypeError
. If the invocation of theDate
constructor is resolved by (1) above, then the assignment totoString
fails as per (2) above. The script should be modified as below to ensure thatassert.throws
only tests the intended statement,s1.toString()
. The modified script tests the intended functionality and passes under Hardened JavaScriptThis is an initial PR to begin the process of adapting test262 for use with Hardened JavaScript. Further changes are expected, with the vast majority likely to fall into the four groups described above.
Thank you to @gibson042, @kriskowal, and @erights for their advice on this work.