Commit Graph

4 Commits

Author SHA1 Message Date
bakkot
8834d5ecb5 Revert of Add errors for declarations which conflict with catch parameters. (patchset #6 id:100001 of https://codereview.chromium.org/2109733003/ )
Reason for revert:
Fuzzer claims `try {  \"\" ; } catch(x) { let x1 = [1,,], x = x; }` causes a crash.

Original issue's description:
> Add errors for declarations which conflict with catch parameters.
>
> Catch parameters are largely treated as lexical declarations in the
> block which contains their body for the purposes of early syntax errors,
> with some exceptions outlined in B.3.5. This patch introduces most of
> those errors, except those from `eval('for (var e of ...);')` inside of
> a catch with a simple parameter named 'e'.
>
> Note that annex B.3.5 allows var declarations to conflict with simple
> catch parameters, except when the variable declaration is the init of a
> for-of statement.
>
> BUG=v8:5112,v8:4231
>
> Committed: https://crrev.com/2907c726b2bb5cf20b2bec639ca9e6a521585406
> Cr-Commit-Position: refs/heads/master@{#37462}

TBR=littledan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5112,v8:4231

Review-Url: https://codereview.chromium.org/2112223002
Cr-Commit-Position: refs/heads/master@{#37464}
2016-07-01 04:28:57 +00:00
bakkot
2907c726b2 Add errors for declarations which conflict with catch parameters.
Catch parameters are largely treated as lexical declarations in the
block which contains their body for the purposes of early syntax errors,
with some exceptions outlined in B.3.5. This patch introduces most of
those errors, except those from `eval('for (var e of ...);')` inside of
a catch with a simple parameter named 'e'.

Note that annex B.3.5 allows var declarations to conflict with simple
catch parameters, except when the variable declaration is the init of a
for-of statement.

BUG=v8:5112,v8:4231

Review-Url: https://codereview.chromium.org/2109733003
Cr-Commit-Position: refs/heads/master@{#37462}
2016-07-01 00:01:31 +00:00
bakkot
9bbba1441a Sloppy-mode function declarations in blocks are now hoisted appropriately.
In ES2016, function declarations nested in blocks are formally allowed. This was
never a part of ECMAScript, but was a common extension. Unfortunately
implementations differed in the exact semantics. Annex B.3.3 in the spec tries
to standardize the parts which are common to different implementations, but does
so with some fairly complicated semantics.

This CL addresses three issues related to annex B.3.3:
* When the outer function had a complex parameter list, no hoisting whatsoever was
  being performed.
* Hoisting was not blocked by parameters of the same name.
* Hoisting was not blocked by nested lexical declarations of the same name.

We had tests which checked for the second, but they were incorrectly passing due to
the first. This CL adds more complete tests.

BUG=v8:5151, v8:5111

Review-Url: https://codereview.chromium.org/2099623003
Cr-Commit-Position: refs/heads/master@{#37405}
2016-06-29 20:55:35 +00:00
adamk
a0a8ecd078 Remove runtime flags for sloppy mode block scoping features
These were all on by default in M49 without complaint.

R=littledan@chromium.org

Review URL: https://codereview.chromium.org/1858943002

Cr-Commit-Position: refs/heads/master@{#35342}
2016-04-08 00:30:20 +00:00