Commit Graph

358 Commits

Author SHA1 Message Date
machenbach
fe97cfccf3 Revert of [es6] Parsing of new.target (patchset #2 id:20001 of https://codereview.chromium.org/1169853002/)
Reason for revert:
[Sheriff] fails messages:
http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20custom%20snapshot%20-%20debug/builds/1703

Original issue's description:
> [es6] Parsing of new.target
>
> BUG=v8:3887
> LOG=N
> R=adamk@chromium.org, dslomov@chromium.org
>
> Committed: https://crrev.com/ae06bdde7763d673b39948b710df414217265cce
> Cr-Commit-Position: refs/heads/master@{#28865}

TBR=adamk@chromium.org,dslomov@chromium.org,arv@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3887

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

Cr-Commit-Position: refs/heads/master@{#28868}
2015-06-09 15:12:18 +00:00
arv
ae06bdde77 [es6] Parsing of new.target
BUG=v8:3887
LOG=N
R=adamk@chromium.org, dslomov@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28865}
2015-06-09 14:28:05 +00:00
arv
8c06568186 [es6] super.prop, eval and lazy functions
We used to only store the uses_super_property in the preparse data
logger. Let the logger use NeedsHomeObject instead.

BUG=v8:3768
LOG=N
R=wingo, adamk

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

Cr-Commit-Position: refs/heads/master@{#28806}
2015-06-04 21:16:32 +00:00
arv
4b8051a02a [es6] Super call in arrows and eval
This splits the SuperReference AST node into SuperPropertyReference and
SuperCallReference. The super call reference node consists of three
unresolved vars to this, new.target and this_function. These gets
declared when the right function is entered and if it is in use. The
variables gets assigned in FullCodeGenerator::Generate.

This is a revert of the revert 88b1c9170a

BUG=v8:3768
LOG=N
R=wingo@igalia.com, adamk@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28769}
2015-06-02 22:04:33 +00:00
caitpotter88
904fbc303a Revert of [es6] implement default parameters via desugaring (patchset #19 id:380001 of https://codereview.chromium.org/1127063003/)
Reason for revert:
Broken on arm64

Original issue's description:
> [es6] implement default parameters via desugaring
>
> Stage 1 implementation:
>
> - Parameters can't be referenced before initialized (from left-to-right)
> - SingleNameBindings only, no support for BindingPatterns
>
> Known issues:
>
> - Incorrect scoping (parameter expressions may reference variables declared in function body)
> - Function arity is untouched
> - Hole-checking needs work
> - Rest parameters are broken when mixed with optional arguments
>
> BUG=v8:2160
> LOG=N
> R=arv@chromium.org, rossberg@chromium.org
>
> Committed: https://crrev.com/892c85485881f8be2f17bd83238980f858126576
> Cr-Commit-Position: refs/heads/master@{#28739}

TBR=rossberg@chromium.org,wingo@igalia.com,arv@chromium.org,dslomov@chromium.org,adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:2160

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

Cr-Commit-Position: refs/heads/master@{#28740}
2015-06-01 18:35:03 +00:00
caitpotter88
892c854858 [es6] implement default parameters via desugaring
Stage 1 implementation:

- Parameters can't be referenced before initialized (from left-to-right)
- SingleNameBindings only, no support for BindingPatterns

Known issues:

- Incorrect scoping (parameter expressions may reference variables declared in function body)
- Function arity is untouched
- Hole-checking needs work
- Rest parameters are broken when mixed with optional arguments

BUG=v8:2160
LOG=N
R=arv@chromium.org, rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28739}
2015-06-01 17:10:50 +00:00
arv
88b1c9170a Revert of [es6] Super call in arrows and eval (patchset #5 id:100001 of https://codereview.chromium.org/1146863007/)
Reason for revert:
Fails

http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%201/builds/579/steps/Check/logs/super

Original issue's description:
> [es6] Super call in arrows and eval
>
> This splits the SuperReference AST node into SuperPropertyReference and
> SuperCallReference. The super call reference node consists of three
> unresolved vars to this, new.target and this_function. These gets
> declared when the right function is entered and if it is in use. The
> variables gets assigned in FullCodeGenerator::Generate.
>
> BUG=v8:3768
> LOG=N
> R=wingo@igalia.com, adamk@chromium.org
>
> Committed: https://crrev.com/673c0516ab96f24343bbb26e0afc2846b5a679df
> Cr-Commit-Position: refs/heads/master@{#28731}

TBR=wingo@igalia.com,adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3768

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

Cr-Commit-Position: refs/heads/master@{#28735}
2015-06-01 16:10:17 +00:00
arv
673c0516ab [es6] Super call in arrows and eval
This splits the SuperReference AST node into SuperPropertyReference and
SuperCallReference. The super call reference node consists of three
unresolved vars to this, new.target and this_function. These gets
declared when the right function is entered and if it is in use. The
variables gets assigned in FullCodeGenerator::Generate.

BUG=v8:3768
LOG=N
R=wingo@igalia.com, adamk@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28731}
2015-06-01 15:02:38 +00:00
arv
44e9810345 [es6] Support super.property in eval and arrow functions
When we enter a method that needs access to the [[HomeObject]]
we allocate a local variable `.home_object` and assign it the
value from the [[HomeObject]] private symbol. Something along
the lines of:

  method() {
    var .home_object = %ThisFunction()[home_object_symbol];
    ...
  }

BUG=v8:3867, v8:4031
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28644}
2015-05-26 20:29:54 +00:00
dslomov
7ffdb5194d [destructuring] Grand for statement parsing unification.
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}
2015-05-21 17:46:45 +00:00
dslomov
a38e3a4518 [destructuring] Implement BindingArrayPattern
(everything except Spread is implemeneted)

R=arv@chromium.org,rossberg@chromium.org,wingo@igalia.com
BUG=v8:811
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28500}
2015-05-20 08:08:14 +00:00
dslomov
5cdaa3e6e5 [destructuring] Implement initializers in patterns.
R=arv@chromium.org,rossberg@chromium.org,wingo@igalia.com
BUG=v8:811
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28482}
2015-05-19 14:29:38 +00:00
dslomov
cf9492ddd8 [destructuring] More tests for object literal pattern
R=arv@chromium.org,rossberg@chromium.org
BUG=v8:811
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28457}
2015-05-18 20:14:51 +00:00
yangguo
fc65e55116 Migrate error messages, part 12.
Review URL: https://codereview.chromium.org/1130133003

Cr-Commit-Position: refs/heads/master@{#28439}
2015-05-18 08:33:51 +00:00
dslomov
7f6ae2300b [destructuring] Adapting PatternRewriter to work in C-style for-statements.
BUG=v8:811
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28417}
2015-05-15 09:56:24 +00:00
wingo
e73594c7fb Use ExpressionClassifier to identify valid arrow function formals
R=dslomov@chromium.org
LOG=N
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28391}
2015-05-13 11:45:02 +00:00
dslomov
5bbe7992db [destructuring] Implement basic binding destructuring infrastructure
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}
2015-05-11 16:28:22 +00:00
vogelheim
be9570027f Implement a 'trial parse' step, that will abort pre-parsing excessively
long and trivial functions, so that they can be eagerly compiled after all.
This essentially allows the parser to renege on its earlier decision to
lazy-parse, if additional information suggests it was a bad decision.

BUG=chromium:470930
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#28252}
2015-05-06 10:21:27 +00:00
wingo
9510a9c3ef Eagerly declare eval scopes, even for sloppy scopes
R=mstarzinger@chromium.org
LOG=N
BUG=N

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

Cr-Commit-Position: refs/heads/master@{#28072}
2015-04-27 12:13:19 +00:00
marja
b03e7a623c Revert of Eagerly declare eval scopes, even for sloppy scopes (patchset #2 id:20001 of https://codereview.chromium.org/1085263003/)
Reason for revert:
Regresses CodeLoad (crbug.com/480774).

Original issue's description:
> Eagerly declare eval scopes, even for sloppy scopes
>
> R=marja@chromium.org, mstarzinger@chromium.org
> LOG=N
> BUG=N
>
> Committed: https://crrev.com/fe9efc121c8cba8b6aee1a9cf36c68ee97c44d99
> Cr-Commit-Position: refs/heads/master@{#28027}

TBR=mstarzinger@chromium.org,verwaest@chromium.org,wingo@igalia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=N

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

Cr-Commit-Position: refs/heads/master@{#28037}
2015-04-24 05:55:25 +00:00
wingo
fe9efc121c Eagerly declare eval scopes, even for sloppy scopes
R=marja@chromium.org, mstarzinger@chromium.org
LOG=N
BUG=N

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

Cr-Commit-Position: refs/heads/master@{#28027}
2015-04-23 09:27:31 +00:00
machenbach
1ea118d592 Revert of Revert of [strong] checking of this & super in constructors (patchset #1 id:1 of https://codereview.chromium.org/1105453002/)
Reason for revert:
Was an infrastructure problem.

Original issue's description:
> Revert of [strong] checking of this & super in constructors (patchset #7 id:110001 of https://codereview.chromium.org/1024063002/)
>
> Reason for revert:
> [Sheriff] Breaks mac gc stress:
> http://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/1024
>
> Original issue's description:
> > [strong] checking of this & super in constructors
> >
> > R=dslomov@chromium.org, marja@chromium.org
> > BUG=v8:3956
> > LOG=N
> >
> > Enforces for constructors that
> > - the only use of 'super' is the super constructor call
> > - the only use of 'this' is a property assignment
> > - both of these must happen at the top-level of the body
> > - 'this' may only be assigned after the 'super' call
> > - 'return' may only be used after the last assignment to 'this'
> >
> > Not yet working for arrow functions (there might be deeper bugs with those).
> >
> > Committed: https://crrev.com/580d66bcda66220d2f3062ac58daf925436df74c
> > Cr-Commit-Position: refs/heads/master@{#27977}
>
> TBR=dslomov@chromium.org,marja@chromium.org,conradw@chromium.org,rossberg@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:3956

TBR=dslomov@chromium.org,marja@chromium.org,conradw@chromium.org,rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3956

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

Cr-Commit-Position: refs/heads/master@{#28001}
2015-04-22 11:04:13 +00:00
machenbach
b3875aacbb Revert of [strong] checking of this & super in constructors (patchset #7 id:110001 of https://codereview.chromium.org/1024063002/)
Reason for revert:
[Sheriff] Breaks mac gc stress:
http://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/1024

Original issue's description:
> [strong] checking of this & super in constructors
>
> R=dslomov@chromium.org, marja@chromium.org
> BUG=v8:3956
> LOG=N
>
> Enforces for constructors that
> - the only use of 'super' is the super constructor call
> - the only use of 'this' is a property assignment
> - both of these must happen at the top-level of the body
> - 'this' may only be assigned after the 'super' call
> - 'return' may only be used after the last assignment to 'this'
>
> Not yet working for arrow functions (there might be deeper bugs with those).
>
> Committed: https://crrev.com/580d66bcda66220d2f3062ac58daf925436df74c
> Cr-Commit-Position: refs/heads/master@{#27977}

TBR=dslomov@chromium.org,marja@chromium.org,conradw@chromium.org,rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3956

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

Cr-Commit-Position: refs/heads/master@{#27991}
2015-04-22 08:00:27 +00:00
rossberg
580d66bcda [strong] checking of this & super in constructors
R=dslomov@chromium.org, marja@chromium.org
BUG=v8:3956
LOG=N

Enforces for constructors that
- the only use of 'super' is the super constructor call
- the only use of 'this' is a property assignment
- both of these must happen at the top-level of the body
- 'this' may only be assigned after the 'super' call
- 'return' may only be used after the last assignment to 'this'

Not yet working for arrow functions (there might be deeper bugs with those).

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

Cr-Commit-Position: refs/heads/master@{#27977}
2015-04-21 16:34:29 +00:00
wingo
8be0499fce Allow eval/arguments in arrow functions
Originally landed in https://codereview.chromium.org/1061983004;
re-landing after re-landing formal parameter parsing refactors.

R=marja@chromium.org
BUG=v8:4020
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27971}
2015-04-21 14:44:03 +00:00
wingo
636cb4f365 Factor formal argument parsing into ParserBase
This commit is a precursor to making lazy arrow function parsing use
similar logic to function(){} argument parsing.

Originally landed in these three CLs:

  https://codereview.chromium.org/1078093002
  https://codereview.chromium.org/1083623002
  https://codereview.chromium.org/1083953002

These were rolled out due to a performance regression on CodeLoad.  This
patchset will fix that by avoiding creation of a DuplicateFinder in the
full parser.

R=marja@chromium.org
BUG=
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27960}
2015-04-21 11:09:34 +00:00
wingo
37520d3e03 Revert "Factor formal argument parsing into ParserBase"
Revert https://codereview.chromium.org/1078093002/ and follow-on parser
patches due to a perf regression.

This reverts commit 53ddccfc33.
This reverts commit 71d3213a3f.
This reverts commit 0f432ebb76.
This reverts commit 1dbc432729.

R=marja@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27912}
2015-04-17 09:51:15 +00:00
conradw
d8bccfe974 [strong] Implement static restrictions on switch statement
Implements the strong mode proposal's restrictions on the syntax of the
switch statement. Also fixes a minor bug with empty statements in strong
mode and improves StrongUndefinedArrow parser synch tests.

BUG=v8:3956
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27885}
2015-04-16 13:29:20 +00:00
wingo
e0913eccfb Simplify DoParseProgram
DoParseProgram doesn't appear to need to receive toplevel scopes as
arguments; it can properly set the end_position of the scopes to the
scanner's position after parsing is complete.

R=marja@chromium.org
BUG=
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27880}
2015-04-16 12:42:37 +00:00
machenbach
c85b22486a Revert of Simplify DoParseProgram (patchset #2 id:20001 of https://codereview.chromium.org/1058363003/)
Reason for revert:
[Sheriff] Changes some layout tests on all platforms, e.g.:
http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2032/builds/2543

Original issue's description:
> Simplify DoParseProgram
>
> DoParseProgram doesn't appear to need to receive toplevel scopes as
> arguments; it can properly set the end_position of the scopes to the
> scanner's position after parsing is complete.
>
> R=marja@chromium.org
> BUG=
> LOG=N
>
> Committed: https://crrev.com/8da9252f61d3c499a78b0b94299c314b2eb0b0c8
> Cr-Commit-Position: refs/heads/master@{#27847}

TBR=marja@chromium.org,wingo@igalia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#27856}
2015-04-15 17:20:21 +00:00
wingo
8da9252f61 Simplify DoParseProgram
DoParseProgram doesn't appear to need to receive toplevel scopes as
arguments; it can properly set the end_position of the scopes to the
scanner's position after parsing is complete.

R=marja@chromium.org
BUG=
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27847}
2015-04-15 13:42:20 +00:00
wingo
71d3213a3f Allow eval/arguments in arrow functions
R=arv@chromium.org, adamk@chromium.org, marja@chromium.org
BUG=v8:4020
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27824}
2015-04-14 15:37:18 +00:00
wingo
0f432ebb76 Refactor formal parameter error locations into a class
This is a follow-up to https://codereview.chromium.org/1078093002.

R=rossberg@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#27780}
2015-04-13 10:39:33 +00:00
wingo
1dbc432729 Factor formal argument parsing into ParserBase
This commit is a precursor to making lazy arrow function parsing use
similar logic to function(){} argument parsing.

R=arv@chromium.org
BUG=4020
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27773}
2015-04-13 08:07:06 +00:00
conradw
3d5717a71b [strong] Implement static restrictions on binding 'undefined' in arrow functions
Implements the strong mode proposal's static restrictions on the use of the
identifier 'undefined', for arrow functions. Assumes these restrictions are
intended to be identical to the restrictions on the use of 'eval and 'arguments'
in strict mode. In addition, Location variables inconsistantly named (e.g.
dupe_error_loc vs dupe_loc) are now consistently named the shorter way.

Baseline: https://codereview.chromium.org/1070633002

BUG=v8:3956
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27756}
2015-04-10 18:27:05 +00:00
conradw
8ef7159582 [strong] Implement static restrictions on binding/assignment to 'undefined'
identifier. Delete unused (and now incorrect) function IsValidStrictVariable.

Implements the strong mode proposal's static restrictions on the use of the
identifier 'undefined'. Assumes these restrictions are intended to be identical
to the restrictions on the use of 'eval' and 'arguments' in strict mode. The
AllowEvalOrArgumentsAsIdentifier enum has been renamed to
AllowRestrictedIdentifiers as logic involving it is now also used for this case.

BUG=v8:3956

LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27744}
2015-04-10 12:04:55 +00:00
caitpotter88
74c381221c [es6] implement spread calls
BUG=v8:3018
R=
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27714}
2015-04-09 19:37:19 +00:00
caitpotter88
ab7d5f9620 [parser] report better errors for multiple ForBindings in ForIn/Of loops
Instead of "unexpected token" errors, report something meatier and more actionable.

BUG=
R=marja@chromium.org, arv@chromium.org
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27677}
2015-04-08 18:47:45 +00:00
caitpotter88
1fb76f055a [es6] emit error when for-in loop declarations are initialized in strict mode
The ES6 grammar forbids the initialization of variable declarations in IterationStatements.

This CL will report `for (var x = y in z)` as a SyntaxError in strict mode (as done in JSC). It is possible that this could break sites in sloppy mode, and so that change can wait.

BUG=
R=
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#27639}
2015-04-07 19:28:42 +00:00
titzer
0389c28ddf Move this_has_uses from ParseInfo back into CompilationInfo and renumber CompilationInfo flags.
R=svenpanne@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#27369}
2015-03-23 14:48:23 +00:00
svenpanne
e396f538d0 Some CompilationInfo-related cleanup.
Use a delegating constructor for CompilationInfo, reducing duplicated
code. Simplified handling of InlinedFunctionInfos on the way: When we
start compiling, we have bigger things to worry about than a default
vector.

Reduced the usage of a SharedFunctionInfo for compiling, this is a
slighty strange concept.

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

Cr-Commit-Position: refs/heads/master@{#27299}
2015-03-19 12:40:00 +00:00
Sven Panne
40567349df Remove funky 2-stage initialization of ParserInfo and an adventurous memset.
R=titzer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27155}
2015-03-12 11:46:32 +00:00
titzer
0f6702562e Extract ParseInfo from CompilationInfo.
Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code).

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27078}
2015-03-09 14:51:24 +00:00
rossberg
054989bd04 [es6] Fix for-const loops
R=dslomov@chromium.org
BUG=3983
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#26971}
2015-03-03 18:34:40 +00:00
adamk
fa293dd79f Re-introduce ImportDeclaration to the parser
This also adds a new VariableMode, IMPORT, which will be
used to do appropriate binding for Import-declared Variables.

Only named imports are handled for now. "import *" and default
import syntaxes have had their TODOs adjusted to match the new
code structure.

BUG=v8:1569
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#26895}
2015-02-26 18:41:04 +00:00
marja
1eddcf5b71 [strong] Declaration-after-use errors.
We cannot yet detect use-before-declaration in general, because for that we'd
need to analyze the context when compiling. But we can detect an error case
where we first see a use, then a declaration.

For this, I also added end position tracking (needed for error messages) to
VariableProxy.

Note: the position naming is completely inconsistent: start_position &
end_position, position & end_position, pos & end_pos, beg_pos & end_pos, to name
a few. This doesn't fix all of it, but tries to unify towards start_position &
end_position whenever possible w/ minimal changes.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#26880}
2015-02-26 13:48:19 +00:00
adamk
fb6f68b8a8 Rename ParseModule to ParseModuleItemList
TBR=rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#26868}
2015-02-25 23:00:32 +00:00
adamk
8b33567fd3 Simplify error message logic in ParseImportNames
The new logic ensures that the error messages are the same in the
"import { <reserved word> }" and "import { foo as <reserved ord> }"
cases.

Also prepares ParseImportNames for returning both the import and local
names to ParseImportClause.

BUG=v8:1569
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#26863}
2015-02-25 19:40:54 +00:00
marja
238ad54d0f Move compilation error handling into a separate class.
In addition to Parser, other phases (such as scope analysis) need to handle
compilation errors in the future. PendingCompilationErrorHandled takes care of
error handling in a unified way.

Split from https://codereview.chromium.org/943543002/ .

R=rossberg@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#26853}
2015-02-25 14:18:34 +00:00
adamk
1a8dc98cbf Fix up ParseProgram and ParseModule to do something sane with module scopes
The FunctionLiteral returned from the parser for modules now has a MODULE_SCOPE,
instead of associating the module scope with a Block inside it. This makes
it easy to get at the ModuleDescriptor from the caller of Parse(), so I've added
a basic test that pokes at the scope and the descriptor. Expect more tests
in this vein.

BUG=v8:1569
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#26836}
2015-02-24 22:39:35 +00:00