[parser] don't report error for CoverInitializedNames in async arrow formals

test/cctest/test-parsing.cc

Index: test/cctest/test-parsing.cc
diff --git a/test/cctest/test-parsing.cc b/test/cctest/test-parsing.cc
index 3c7822a03209f55c7888e27c05e2cdf1622b8f6c..4bf9c50e2a02b8f0a8ae91f3b830d909a0d4a8cf 100644
--- a/test/cctest/test-parsing.cc
+++ b/test/cctest/test-parsing.cc
@@ -7504,6 +7504,9 @@ TEST(AsyncAwait) {
     "var O = { async 'method'() { await 1; } }",
     "var O = { async 0() { await 1; } }",
     "async function await() {}",
+
+    "var asyncFn = async({ foo = 1 }) => foo;",
+    "var asyncFn = async({ foo = 1 } = {}) => foo;",
     NULL
   };
   // clang-format on
@@ -7665,6 +7668,10 @@ TEST(AsyncAwaitErrors) {
     "(async`foo`.bar => 1)",
     "(async`foo`.bar foo => 1)",
     "(async`foo`.bar () => 1)",
+
+    // v8:5148 assert that errors are still thrown for calls that may have been
+    // async functions
+    "async({ foo = 1 })",

[Dan Ehrenberg, 2016/06/24 17:30:41]

Maybe verify that await is banned in this context 

[caitp (gmail), 2016/06/24 18:05:40]

why would await be banned in this context, other than in a module?

`async({ await = 1 }) => 1` would be an error, but is currently only reported as
an error in the full parser, not the preparser, so I think that's a separate
issue (similar to other cases where arrow functions don't produce early errors
in the preparser).

[Dan Ehrenberg, 2016/06/24 18:30:14]

test-parsing.cc has a way of invoking just the parser. We should take advantage
of that mode to test these things.

[caitp (gmail), 2016/06/24 19:24:43]

I've added tests and a TODO, will deal with fixing the banned "await" parameter
separately.

     NULL
   };