[es7] implement |do| expressions proposal

test/mjsunit/internal-do-expressions.js

Index: test/mjsunit/internal-do-expressions.js
diff --git a/test/mjsunit/internal-do-expressions.js b/test/mjsunit/internal-do-expressions.js
new file mode 100644
index 0000000000000000000000000000000000000000..4cd603d9af08a3eba6e3ccf1e2d06dccf1998f7c
--- /dev/null
+++ b/test/mjsunit/internal-do-expressions.js
@@ -0,0 +1,57 @@
+// Copyright 2015 the V8 project authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// Flags: --do-expression-parsing --harmony-sloppy-let
+
+// This feature is not currently on the standards track. --do-expression-parsing

[rossberg, 2015/10/13 10:44:33]

It is, though still at stage 0.

[caitp (gmail), 2015/10/13 15:06:00]

Acknowledged.

+// exists for the testing of the internal implementation, intended to be used
+// to desugar certain sequences more easily. It may be removed in the future.
+
+function returnValue(v) { return v; }
+function MyError() {}
+
+function TestBasic() {

[rossberg, 2015/10/13 10:44:33]

The most important thing to test is all sorts of statements within a non-trivial
expression context, i.e., one where the operand stack isn't empty:

x + do{...}
f(do{...})

etc. I assume this will not work out of the box, in particular not with
deoptimisation.

[caitp (gmail), 2015/10/13 15:06:00]

For every case I've tried, it seems to work (although there was an issue in
crankshaft due to bailouts when visiting the `do` block that wasn't handled,
which I'll fix in the next patchset).

It's hard to get enough coverage for this, but I've added some more tests, and
some suggestions for others would be very helpful

[rossberg, 2015/10/15 09:58:27]

Some other scenarios to test:

- Uses of break and continue inside the do (i.e., those that don't escape -- I
think they should work out of the box).
- Uses of throw inside the do, both caught inside or outside the do.
- Various completion values (cf. the existing completion.js).
- Different forms of declarations inside the do (esp. hoisting of var).
- Sloppy eval with var declaration. :)
- Do in some more esoteric positions, like default parameters, decl
initialisers, `return` -- especially do that throws or has var declarations
- Deopts triggered inside the do.
- Conversely, OSR inside the do, i.e., a long-running for-loop that gets
optimised in the middle.

I'm fine with leaving these for follow-up CLs, just dropping a list of
everything that might be problematic and should eventually be tested. :)

[caitp (gmail), 2015/10/15 11:24:17]

Ah yes, I'll add more

+  // Looping and lexical declarations
+  assertEquals(512, returnValue(do {
+    let n = 2;
+    for (let i = 0; i < 4; i++) n <<= 2;
+  }));
+
+  // Strings do the right thing
+  assertEquals("spooky halloween", returnValue(do {
+    "happy halloween".replace('happy', 'spooky');
+  }));
+
+  // Do expressions with no completion produce an undefined value
+  assertEquals(undefined, returnValue(do {}));
+  assertEquals(undefined, returnValue(do { var x = 99; }));
+  assertEquals(undefined, returnValue(do { function f() {}; }));
+  assertEquals(undefined, returnValue(do { let z = 33; }));
+
+  // Propagation of exception
+  assertThrows(function() {
+    (do {
+      throw new MyError();
+      "potatoes";
+    });
+  }, MyError);
+
+  // Real-world use case for desugaring
+  var array = [1, 2, 3, 4, 5], iterable = [6, 7, 8,9];
+  assertEquals([1, 2, 3, 4, 5, 6, 7, 8, 9], do {
+    for (var element of iterable) array.push(element);
+    array;
+  });
+
+  // Nested do-expressions
+  assertEquals(125, do { (do { (do { 5 * 5 * 5 }) }) });
+
+  // Directives are not honoured
+  (do {
+    "use strict";
+    foo = 80;
+    assertEquals(foo, 80);
+  });
+}
+TestBasic();