Fix function scoping issue

test/mjsunit/regress/regress-520029.js

Index: test/mjsunit/regress/regress-520029.js
diff --git a/test/mjsunit/regress/regress-520029.js b/test/mjsunit/regress/regress-520029.js
new file mode 100644
index 0000000000000000000000000000000000000000..141ea40b724649565bda35211ef6ce57ff03368d
--- /dev/null
+++ b/test/mjsunit/regress/regress-520029.js
@@ -0,0 +1,45 @@
+// 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: --harmony-sloppy-let --harmony-sloppy
+
+// Test that hoisting a function out of a lexical scope does not
+// lead to a parsing error
+
+function f(one) { class x { } { class x { } function g() { one; x; } g() } } f()
+
+function g() { var x = 1; { let x = 2; function g() { x; } g(); } }
+assertEquals(undefined, g());
+
+function __f_4(one) {
+  var __v_10 = one + 1;
+  {
+    let __v_10 = one + 3;
+    function __f_6() {
+ one;
+ __v_10;
+    }
+    __f_6();
+  }
+}
+__f_4();
+
+try {

[adamk, 2015/08/21 21:39:04]

Is this try/catch doing anything?

[Dan Ehrenberg, 2015/08/21 23:04:31]

Yes, it's defining a function __f_14() which references a lexically scoped local
variable. I had thought that this was enough to trigger
https://code.google.com/p/chromium/issues/detail?id=520891 , but apparently not.
I dedup'd that bug and deleted this "test".

+} catch (__v_14) {
+  function __f_14() { return __v_14; }
+}
+
+assertThrows(() => {
+  function __f_21() { }

[adamk, 2015/08/21 21:39:04]

Is this function doing anything?

[Dan Ehrenberg, 2015/08/21 23:04:31]

Not sure, it does something to the scopes but I actually can't repro the
original issue (see below).

+  try {
+    throw 2;
+  } catch(b) {
+    n = __f_22;
+    function __f_22() {
+      return b + c;
+    }
+    let c = 3;
+  }
+  n();
+}, ReferenceError);

[adamk, 2015/08/21 21:39:04]

Sorry, I'm missing something; why does this cause a reference error?

[Dan Ehrenberg, 2015/08/21 23:04:31]

You're right, this doesn't actually make sense. Another case of me misdiagnosing
a dup bug, and quickly concluding that I fixed it just because it didn't crash
the parser with this patch (it didn't before either). Removed this from the
test.