Implement ES2015 const

[p-bakker]

While Rhino has a const implementation, it is based on a draft EcmaScript specification that precedes the official ECMAScript 2015 specification in which const got introduced. As such, the current const implementation is far from standards compliant.

The const specification in ECMAScript 2015 is pretty closely aligned with the let implementation in the same spec, with the major difference being that const's cannot be updated, while let's can.

So, a possible implementation path is to piggy-back off of the let implementation and put the old const implementation behind a flag. Need to decide which flag this will be. Should the flag just be the JavaScript version flag and make a breaking change to Context.VERSION_ES6?

Note 1: the let implementation also has some non-standard extensions based on old draft specifications (that should not be enabled for the const implementaiton when piggy-backing off of the let implementation), see #923
Note 2: the let implementation doesn't support Temporal Dead Zone, see #969
Note 3: looks like the let implementation has some scoping issues: #834

[p-bakker]

Related issues: #647, #719 and #326

[tonygermano]

I'm honestly not sure that the old behavior needs to be preserved at all. Are there any situations where fixing const would break code that was previously working?

To my knowledge the current implementation is more restrictive than it needs to be, preventing its use in the first place where it should be allowed.

[p-bakker]

Have a look at the related cases mentioned above: I think there are several cases where, if we'd just implement the correct behavior, existing code that depends on the current behavior, would break.

How likely is that and does it warrant putting the new (or old) behavior behind a (language version) flag idk...

[p-bakker]

Due to the non-standard const impl. of Rhino, a for (const x of/in ...) { const y = ...} loop bombs out for various reasons.

As the test262 harness code uses this (conditionally for testing unicode regexes), this case is sorta a blocker for Support ES2015 Regex u flag (Unicode).

Locally one can change the harness code to use a let instead (for (let x of string) {...}) and see if all the unicode regex tests pass, but in our CI the test would fail, so would have to be marked as failing not to fail the build

[tuchida]

How about transpiling the harness code with Babel?
I could use this.

diff --git a/build.gradle b/build.gradle
index a05bfcb6..282bcbbd 100644
--- a/build.gradle
+++ b/build.gradle
@@ -9,6 +9,7 @@ plugins {
     id 'checkstyle'
     id 'com.diffplug.spotless' version "5.12.1"
     id 'com.github.spotbugs' version "4.7.1"
+    id 'com.github.bryncooke.babel-gradle' version '1.0.1'
 }
 
 tasks.withType(JavaCompile) {
@@ -513,4 +514,10 @@ distTar {
     archiveExtension = 'tar.gz'
 }
 
+babel {
+    presets "es2015"
+    inputDir = file("test262/harness/")
+    outputDir = file("testsrc/build/test262/harness/")
+}
+
 distZip.dependsOn javadoc, jar, sourceJar, runtimeSourceJar
diff --git a/testsrc/org/mozilla/javascript/tests/Test262SuiteTest.java b/testsrc/org/mozilla/javascript/tests/Test262SuiteTest.java
index 1ed9dfb5..70687de2 100644
--- a/testsrc/org/mozilla/javascript/tests/Test262SuiteTest.java
+++ b/testsrc/org/mozilla/javascript/tests/Test262SuiteTest.java
@@ -69,7 +69,7 @@ public class Test262SuiteTest {
     static final int[] OPT_LEVELS;
 
     private static final File testDir = new File("test262/test");
-    private static final String testHarnessDir = "test262/harness/";
+    private static final String testHarnessDir = "testsrc/build/test262/harness/";
     private static final String testProperties;
 
     private static final boolean updateTest262Properties;

./package.json

{
  "name": "example",
  "version": "1.0.0",
  "dependencies": {
    "babel-preset-es2015": "^6.24.1"
  },
  "devDependencies": {
    "babel-cli": "^6.26.0"
  },
  "author": "",
  "license": "ISC",
  "description": ""
}

Now it works.

$ npm install
$ ./gradlew babel
$ ./gradlew test --tests Test262SuiteTest --rerun-tasks -DupdateTest262properties

You can get it to work by having the developer install npm or by including the converted code in the repository.
I have not checked the license.

[p-bakker]

Its definetly something that would at least allow us to run against the latest test262 version, so from that point of view we could do this

If we do, I think that:

• we should configure Babel to use Rhino as target (Update compat data (specifically for rhino 1.7.14) babel/babel#14208)
• we maybe should run the harness tests as well: https://github.com/tc39/test262/tree/main/test/harness

The only downside of going this route is that there might be less urgency to fix the issues/implement the missing features in Rhino that require us to use Babel.

Anyone else got opinions?

[p-bakker]

And maybe also somehow have a way to run test262 without transpiling the harness code using Babel