This is in preparation for the addition of --harmony-destructuring-assignment.
BUG=v8:811
LOG=n
Review URL: https://codereview.chromium.org/1450193002
Cr-Commit-Position: refs/heads/master@{#32098}
Reason for revert:
MSAN errors on arm64: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/5123/
Original issue's description:
> [es6] Implement destructuring binding in try/catch
>
> The approach is to desugar
>
> try { ... }
> catch ({x, y}) { ... }
>
> into
>
> try { ... }
> catch (.catch) {
> let x = .catch.x;
> let y = .catch.y;
> ...
> }
>
> using the PatternRewriter's normal facilities. This has the side benefit
> of throwing the appropriate variable conflict errors for declarations
> made inside the catch block.
>
> No change is made to non-destructured cases, which will hopefully save
> us some work if https://github.com/tc39/ecma262/issues/150 is adopted
> in the spec.
>
> There's one big problem with this patch, which is a lack of PreParser
> support for the redeclaration errors. But it seems we're already lacking
> good PreParser support for such errors, so I'm not sure that should
> block this moving forward.
>
> BUG=v8:811
> LOG=y
>
> Committed: https://crrev.com/a316db995e6e4253664920652ed4e5a38b2caeba
> Cr-Commit-Position: refs/heads/master@{#31797}
TBR=rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:811
Review URL: https://codereview.chromium.org/1408063013
Cr-Commit-Position: refs/heads/master@{#31798}
The approach is to desugar
try { ... }
catch ({x, y}) { ... }
into
try { ... }
catch (.catch) {
let x = .catch.x;
let y = .catch.y;
...
}
using the PatternRewriter's normal facilities. This has the side benefit
of throwing the appropriate variable conflict errors for declarations
made inside the catch block.
No change is made to non-destructured cases, which will hopefully save
us some work if https://github.com/tc39/ecma262/issues/150 is adopted
in the spec.
There's one big problem with this patch, which is a lack of PreParser
support for the redeclaration errors. But it seems we're already lacking
good PreParser support for such errors, so I'm not sure that should
block this moving forward.
BUG=v8:811
LOG=y
Review URL: https://codereview.chromium.org/1417483014
Cr-Commit-Position: refs/heads/master@{#31797}
Previously, cases like
var [foo]
led to a parser crash because the parser tried to do something with
the initializer, which was not syntactically present.
This patch fixes the parser issue (implicitly creating an undefined
initializer) and inserts a check for array destructuring that the
right-hand side is coercible to an object, so it can have iterator
methods called on it safely.
BUG=v8:4462
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1384413002
Cr-Commit-Position: refs/heads/master@{#31128}
Previously, using legacy const in for-of/in loops led to a check-fail
in the parser. This was due to the fact that the destructuring bind
led to an undefined initialization to undefined in the parser, which
caused the for loop code to go down a strange path. This patch
eliminates the undefined initialization in variables declared in
for-in/of loops, so that that path is not used and the error is
fixed.
BUG=v8:4461
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1385913003
Cr-Commit-Position: refs/heads/master@{#31117}
Var-bindings may shadow parameters from a non-simple parameter list. When that happens: they create separate bindings, but are initialised with the respective parameter value. Thus:
(function(x, f = () => x) { var x; var y = x; x = 2; return [x, y, f()] })(1) --> [2, 1, 1]
This CL implements that by inserting a suitable assignment for every shadwowing var-variable (e.g., x = outer_x above) at the beginning of the function's body block.
R=adamk@chromium.org
BUG=v8:4440,v8:811
LOG=N
Review URL: https://codereview.chromium.org/1371333004
Cr-Commit-Position: refs/heads/master@{#31042}
Arrow functions have been enabled by default since the 4.5 branch.
Review URL: https://codereview.chromium.org/1373633002
Cr-Commit-Position: refs/heads/master@{#31031}
Add support for `get` and `set` as shorthand properties. Also
supports them for CoverInitializedName in BindingPatterns and (once implemented)
AssignmentPatterns.
BUG=v8:4412, v8:3584
LOG=N
R=adamk, aperez, wingo, rossberg
Review URL: https://codereview.chromium.org/1328083002
Cr-Commit-Position: refs/heads/master@{#30769}
TC39 agreed to disallow "use strict" directives in function body when
non-simple parameter lists are used.
This is a continuation of caitp's CL https://codereview.chromium.org/1281163002/
with some refactorings removed for now.
Still TODO: there is a lot of duplication between the is_simple field of
FormalParametersBase and the NonSimpleParameter property ExpressionClassifier
keeps track of. It should be possible to remove the former with a minor
refactoring of arrow function parsing. This will be attempted in a follow-up CL.
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1300103005
Cr-Commit-Position: refs/heads/master@{#30388}
Previously, examples like (({a = x}, x) => {})({}, 0) did not throw a ReferenceError like they should. This CL
- Splits up DeclareFormalParameters such that the formals can be recorded first and declared later.
- Declaration then takes the complete parameter list into account. If it is not simple, temporaries are introduced for all parameters.
- BuildParameterInitializationBlock desugars all parameters from non-simple lists into let-bindings.
- Refactored Pre/ParserFormalParameters, so that the arity information is no longer duplicated in Parser.
- Rest is currently handled specially, until rest-via-destructuring has landed.
R=adamk@chromium.org, littledan@chromium.org
BUG=v8:811
LOG=N
Review URL: https://codereview.chromium.org/1259283002
Cr-Commit-Position: refs/heads/master@{#30025}
The enumerable expression in a for-in/of loop is supposed to have a TDZ for any
lexically bound names in that loop (there can be more than one with destructuring).
This patch accomplishes this with an almost-correct desugaring. The only thing missing
is proper debugger support (the let declarations added by the desugaring, while invisible
to code due to shadowing, are visible to the debugger).
BUG=v8:4210
LOG=n
Review URL: https://codereview.chromium.org/1218543003
Cr-Commit-Position: refs/heads/master@{#29396}
Also support patterns in ``for (var p in/of ...)``
This CL extends the rewriting we used to do for ``for (let p in/of...)`` to
``for (var p in/of ...)``. For all for..in/of loop declaring variable,
we rewrite
for (var/let/const pattern in/of e) b
into
for (x' in/of e) { var/let/const pattern = e; b }
This adds a small complication for debugger: for a statement
for (var v in/of e) ...
we used to have
var v;
for (v in/of e) ...
and there was a separate breakpoint on ``var v`` line.
This breakpoint is actually useless since it is immediately followed by
a breakpoint on evaluation of ``e``, so this CL removes that breakpoint
location.
Similiraly, for let, it used to be that
for (let v in/of e) ...
became
for (x' in/of e) { let v; v = x'; ... }
``let v``generetaed a useless breakpoint (with the location at the
loop's head. This CL removes that breakpoint as well.
R=arv@chromium.org,rossberg@chromium.org
BUG=v8:811
LOG=N
Review URL: https://codereview.chromium.org/1149043005
Cr-Commit-Position: refs/heads/master@{#28565}
This patch:
- Refactors Parser::ParseVariableDeclarations
- Introduces Parser::PatternMatcher class
- Implements matching a single variable pattern
- Implements rudimentary matching against object literal pattern
as a proof of concept
R=arv@chromium.org,rossberg@chromium.org
BUG=v8:811
LOG=N
Review URL: https://codereview.chromium.org/1130623004
Cr-Commit-Position: refs/heads/master@{#28345}
