Commit Graph

183 Commits

Author SHA1 Message Date
svenpanne@chromium.org
b5220b20bc Fix checks to bit flags of PreParserExpression
This fixes checks on the "code_" member of PreParserExpression, in order
to make methods IsThis(), IsThisProperty(), IsProperty(), IsCall() and
IsValidReferenceExpression() work correctly.

BUG=v8:3456
LOG=
R=svenpanne@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22562 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-23 13:29:24 +00:00
rossberg@chromium.org
8023c9f564 Implement basic code generation for arrow functions
Implements code generation for arrow functions by desugaring them into
a FunctionLiteral. For the moment, a normal FUNCTION_SCOPE is used, so
"this" and "arguments" behave as in normal functions. Implementing the
correct scoping rules is to be done later on.

BUG=v8:2700
LOG=
R=rossberg@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22495 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-21 09:58:01 +00:00
marja@chromium.org
70da8959bc Implement handling of arrow functions in the parser
Arrow functions are parsed from ParseAssignmentExpression(). Handling the
parameter list is done by letting ParseConditionalExpression() parse a comma
separated list of identifiers, and it returns a tree of BinaryOperation nodes
with VariableProxy leaves, or a single VariableProxy if there is only one
parameter. When the arrow token "=>" is found, the VariableProxy nodes are
passed to ParseArrowFunctionLiteral(), which will then skip parsing the
paramaeter list. This avoids having to rewind when the arrow is found and
restart parsing the parameter list.

Note that the empty parameter list "()" is handled directly in
ParsePrimaryExpression(): after is has consumed the opening parenthesis,
if a closing parenthesis follows, then the only valid input is an arrow
function. In this case, ParsePrimaryExpression() directly calls
ParseArrowFunctionLiteral(), to avoid needing to return a sentinel value
to signal the empty parameter list. Because it will consume the body of
the arrow function, ParseAssignmentExpression() will not see the arrow
"=>" token as next, and return the already-parser expression.

The implementation is done in ParserBase, so it was needed to do some
additions to ParserBase, ParserTraits and PreParserTraits. Some of the
glue code can be removed later on when more more functionality is moved
to ParserBase.

Additionally, this adds a runtime flag "harmony_arrow_functions"
(disabled by default); enabling "harmony" will enable it as well.

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

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

Patch from Adrián Pérez de Castro <aperez@igalia.com>.

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22366 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-14 07:55:45 +00:00
marja@chromium.org
938b57f75b Revert "Implement handling of arrow functions in the parser"
This reverts revision 22320.

Reason: ASAN still detects leaks!

Conflicts:
	src/preparser.h

TBR=aperez@igalia.com,marja@chromium.org
BUG=

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22337 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-11 06:39:31 +00:00
rossberg@chromium.org
e274edc8b8 Make let usable as an identifier in ES6 sloppy mode.
All of our mjsunit suite now runs through with --harmony-scoping enabled, up to expected failures (tests checking syntax errors for const/function in strict mode).

R=marja@chromium.org, ulan@chromium.org
BUG=v8:2198
LOG=Y

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22323 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-10 14:06:37 +00:00
marja@chromium.org
e5991fc373 Implement handling of arrow functions in the parser
Arrow functions are parsed from ParseAssignmentExpression(). Handling the
parameter list is done by letting ParseConditionalExpression() parse a comma
separated list of identifiers, and it returns a tree of BinaryOperation nodes
with VariableProxy leaves, or a single VariableProxy if there is only one
parameter. When the arrow token "=>" is found, the VariableProxy nodes are
passed to ParseArrowFunctionLiteral(), which will then skip parsing the
paramaeter list. This avoids having to rewind when the arrow is found and
restart parsing the parameter list.

Note that the empty parameter list "()" is handled directly in
ParsePrimaryExpression(): after is has consumed the opening parenthesis,
if a closing parenthesis follows, then the only valid input is an arrow
function. In this case, ParsePrimaryExpression() directly calls
ParseArrowFunctionLiteral(), to avoid needing to return a sentinel value
to signal the empty parameter list. Because it will consume the body of
the arrow function, ParseAssignmentExpression() will not see the arrow
"=>" token as next, and return the already-parser expression.

The implementation is done in ParserBase, so it was needed to do some
additions to ParserBase, ParserTraits and PreParserTraits. Some of the
glue code can be removed later on when more more functionality is moved
to ParserBase.

Additionally, this adds a runtime flag "harmony_arrow_functions"
(disabled by default); enabling "harmony" will enable it as well.

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

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

Patch from Adrián Pérez de Castro <aperez@igalia.com>.

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22320 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-10 12:27:07 +00:00
marja@chromium.org
c393b9a576 Revert "Implement handling of arrow functions in the parser"
This reverts r22265.

Reason: ASAN tests fail.

BUG=
TBR=marja@chromium.org,aperez@igalia.com

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22266 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-08 07:48:22 +00:00
marja@chromium.org
7367720daa Implement handling of arrow functions in the parser
Arrow functions are parsed from ParseAssignmentExpression. Handling the
parameter list is done by letting ParseConditionalExpression() parse
a comma-separated list of identifiers, and it returns a tree of
BinaryOperation nodes with VariableProxy leaves, or a single
VariableProxy if there is only one parameter. When the arrow token "=>"
is found, the VariableProxy nodes are passed to ParseFunctionLiteral(),
which will then skip parsing the paramaeter list. This avoids having
to rewind when the arrow is found and restart parsing the parameter
list. Note that ParseExpression() expects parenthesized expressions
to not be empty, so checking for a closing parenthesis is added in
handling the empty parameter list "()" will accept a right-paren and
return an empty expression, which means that the parameter list is
empty.

Additionally, this adds the following machinery:

 - A runtime flag "harmony_arrow_functions" (disabled by default).
   Enabling "harmony" will enable it as well.
 - An IsArrow bit in SharedFunctionInfo, and accessors for it.
 - An IsArrow bit in FunctionLiteral, accessorts for it, and
   a constructor parameter to set its value.
 - In ParserBase: allow_arrow_functions() and set_allow_arrow_functions()
 - A V8 native %FunctionIsArrow(), which is used to skip adding the
   "function " prefix when getting the source code for an arrow
   function.

R=marja@chromium.org

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

Patch from Adrián Pérez de Castro <aperez@igalia.com>.

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22265 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-08 07:11:13 +00:00
ishell@chromium.org
ff134a1939 Stack overflow checkers are now compatible with ASAN's detect_stack_use_after_return mode.
BUG=chromium:376287
BUG=chromium:376262
BUG=chromium:369962
LOG=N
R=jkummerow@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22183 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-03 08:52:28 +00:00
wingo@igalia.com
341d61867c Allow yield expressions without a RHS.
R=marja@chromium.org
BUG=

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22163 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-02 13:48:28 +00:00
rossberg@chromium.org
cb2419c615 Infer whether a variable is assigned in inner functions
R=titzer@chromium.org
BUG=

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22039 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-26 11:59:42 +00:00
wingo@igalia.com
3454a45f5d Test that trailing commas in object literals are allowed
ES6 will allow trailing commas in object literals.  It turns out that V8
already allowed it, too, as does JSC and SpiderMonkey.

R=marja@chromium.org
BUG=

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22005 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-25 10:13:10 +00:00
marja@chromium.org
62ffc7de20 New try: Parser: Delay internalizing strings and values
This is a reincarnation of r21841.

The previous try was https://codereview.chromium.org/314603004/ but it regressed
JSBench and morejs.

BUG=
R=rossberg@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21972 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-24 14:03:24 +00:00
marja@chromium.org
1fd638e284 Parser: Refactor strict mode checks for functions
Moves the strict mode checks and error reporting for the function and
parameter names into a separate CheckStrictFunctionNameAndParameters()
function in ParserBase. Parsing of arrow functions will then use this
new function instead of duplicating the error code.

BUG=
R=marja@chromium.org

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

Patch from Adrián Pérez de Castro <aperez@igalia.com>.

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21896 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-20 09:45:05 +00:00
mstarzinger@chromium.org
fec6e62dfb Check alpha-sorting of includes during presubmit.
R=rossberg@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21894 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-20 08:40:11 +00:00
marja@chromium.org
9ad39a8043 Revert "Parser: Delay internalizing strings and values." (r21841)
Plus the fixes on top.

Reason: regresses benchmarks (JSBench) and perf (morejs).

TBR=rossberg@chromium.org
BUG=385404
LOG=N

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21882 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-18 07:30:56 +00:00
marja@chromium.org
5bbc92dee0 Throw syntax error when a getter/setter has the wrong number of params
We used to allow any number of parameters in getters and setters to
match JSC. This is a violation of ES5.1 and both SpiderMonkey and
Chakra throw on these syntax errors.

BUG=v8:3371
LOG=Y
R=marja@chromium.org

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

Patch from Erik Arvidsson <arv@chromium.org>.

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21868 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-17 07:23:26 +00:00
marja@chromium.org
a290cf8cda Parser: Delay internalizing strings and values.
This is needed so that we can run Parser on a non-main thread (independent
of the Isolate and the V8 heap).

BUG=
R=rossberg@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21841 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-13 13:31:56 +00:00
marja@chromium.org
b6a8f739ea Misc cleanup (split from the "delay string / value internalization" CL).
- Missing includes / forward declaration
- Parser: Simplifying calling error reporting funcs.

R=ulan@chromium.org
BUG=

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21652 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-03 16:12:48 +00:00
jochen@chromium.org
56a486c322 Use full include paths everywhere
- this avoids using relative include paths which are forbidden by the style guide
- makes the code more readable since it's clear which header is meant
- allows for starting to use checkdeps

BUG=none
R=jkummerow@chromium.org, danno@chromium.org
LOG=n

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-03 08:12:43 +00:00
marja@chromium.org
11b8551f60 Parser / PreParser: Simplify error message arguments.
In some places, we pretended that there can be multiple arguments, though in
practice there was only one. In other places (most importantly, PreParser), we
only handled one argument. (This means that we were not able to produce a
multi-argument error inside a lazy function anyway.)

This CL makes it clear that there is ever only one argument.

R=ulan@chromium.org
BUG=

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21324 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-05-15 09:44:57 +00:00
bmeurer@chromium.org
d4b533d41b Bulk update of Google copyright headers in source files.
R=svenpanne@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-29 06:42:26 +00:00
marja@chromium.org
2dd4b5f938 Parser: Introduce StatementList + NewStatementList()
Adds new Traits::Type::StatementList definitions both for Parser and
PreParser, and the corresponding NewStatementList() factory function.
This is needed to be able to define in ParserBase parsing functions
that return and manipulate lists of statements.

Moving and renaming PreParser::Statement to PreParserStatement is also
needed so its definition is available earlier for PreParserStatementList
to use it.

R=marja@chromium.org

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

Patch from Adrian Perez de Castro <aperez@igalia.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20965 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-25 09:44:20 +00:00
marja@chromium.org
a6db82d81e Tiny Parser fix: init identifiers.
This bug went unnoticed because PreParserIdentifier and Handle<String> have
default ctors which create a null identifier, but this it not true for all
possible identifier types (especially pointers).

R=ulan@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20834 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-17 09:23:04 +00:00
marja@chromium.org
ed1d232d5d Parser cleanup: PreParser doesn't need to produce symbol data any more.
State of the art:
- Chromium doesn't do a separate preparsing phase any more.
- We start parsing with Parser, and when it sees a lazy function, it falls back
to PreParser for that function.
- The symbol data should contain symbols which are *outside* lazy functions.
- So Parser should always produce symbol data, and PreParser should never.
- Because it's this simple now, we don't need to keep track of "should
produce symbol data" (i.e., whether we're inside a lazy func or not).

R=ulan@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20707 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-14 08:49:23 +00:00
rossberg@chromium.org
2fda95eb80 Make stray 'return' an early error
As required by the spec, and implemented by other browsers.

(Plus minor clean-up for redeclaration TypeErrors.)

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

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20434 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-02 12:38:01 +00:00
rossberg@chromium.org
45118bfdfb Make invalid LHSs that are calls late errors
Necessary for web legacy compatibility.

Also fold in additional strict mode checks into LHS checks.
Minor constness clean-ups on the way.

R=marja@chromium.org
BUG=chromium:358346
LOG=Y

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20428 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-02 11:03:05 +00:00
marja@chromium.org
6608110e87 Make it clearer that PreParser doesn't depend on Isolate.
The Isolate* member of ParserBase::FunctionState was only used by
Parser. Removing it makes it clear that there are no isolates in
PreParser. (There's also no Zone, since PreParserTraits::Type::Zone is void.)

R=yangguo@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20331 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-28 12:49:34 +00:00
marja@chromium.org
25260c2b9a PreParser cleanup: no need to track with-ness of scopes.
Historically, we used to track the "with-ness" of a scope differently; not
creating a with scope, but setting a property on the scope (see
https://codereview.chromium.org/5166006 ). For laziness decisions, checking the
with-ness should be unnecessary: the current scope is function scope, and if the
outer scope is global scope, there's surely no with scope in between.

R=ulan@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20189 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-24 12:16:09 +00:00
marja@chromium.org
e79ff8275c Move new expression parsing funcs to ParserBase.
Functions moved: ParseMemberWithNewPrefixesExpression, ParseMemberExpression,
ParseMemberExpressionContinuation.

Now all Parse*Expression functions are in ParserBase.

R=mstarzinger@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20153 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-21 10:34:51 +00:00
marja@chromium.org
7708d4a22d Move ParseLeftHandSideExpression to ParserBase.
Includes cleanups:
- Reorganized functions in PreParserFactory to be in the logical order.
- De-hackified things PreParser doesn't need to track, such as IsCall & IsCallNew.

R=mstarzinger@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20150 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-21 09:51:33 +00:00
marja@chromium.org
8452030817 Move ParsePostfixExpression into ParserBase.
+ enable a test which checks that Parser and PreParser produce the "invalid left
hand side" errors consistently.

R=mstarzinger@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20149 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-21 09:46:18 +00:00
marja@chromium.org
d017e6ce54 Make PreParser track valid left hand sides.
Notes:
- This makes PreParser produce invalid_lhs_in_assignment and
invalid_lhs_in_prefix_op. Other errors will follow as the corresponding funcs
move to ParserBase.
- PreParserExpression::IsStrictFunction and StrictFunction() are not needed any
more -> removed them.

R=rossberg@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20125 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-20 13:18:15 +00:00
marja@chromium.org
e9717833f9 Move ParseUnaryExpression into ParserBase and add tests.
This also makes PreParser produce the strict_delete error the same way as
Parser (see test).

R=rossberg@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20079 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-19 14:08:47 +00:00
marja@chromium.org
c04dd3fb7f Revert "Move ParseUnaryExpression into ParserBase and add tests."
This reverts revision 20077.

Reason: build fail on some compilers.

BUG=
TBR=marja@chromium.org,rossberg@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20078 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-19 13:58:15 +00:00
marja@chromium.org
f4ef82309a Move ParseUnaryExpression into ParserBase and add tests.
This also makes PreParser produce the strict_delete error the same way as
Parser (see test).

R=rossberg@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20077 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-19 13:42:41 +00:00
marja@chromium.org
932a29a66a New compilation API, part 2.
This CL makes the Parser produce the data PreParser used to produce. This
enables us to get rid of the unnecessary preparsing phase.

The first part is here: https://codereview.chromium.org/199063003/

BUG=
R=dcarney@chromium.org, svenpanne@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20075 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-19 13:24:13 +00:00
marja@chromium.org
934e58d3a3 (Pre)Parser unification: use shorter type names.
R=mstarzinger@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20044 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-18 17:05:38 +00:00
marja@chromium.org
9b94d12fd7 Move ParseBinaryExpression to ParserBase.
R=mstarzinger@chromium.org
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19997 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-17 13:54:42 +00:00
marja@chromium.org
6cf32b134a Move ParseConditionalExpression to ParserBase.
R=mstarzinger@chromium.org
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19994 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-17 13:36:39 +00:00
rossberg@chromium.org
1174e9233d Fix C++ compilation issue
TBR=marja@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19977 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-17 10:28:53 +00:00
rossberg@chromium.org
c3c185c173 Make invalid LHSs a parse-time (reference) error
This is required by the spec. It also prevents crashes resulting from the attempt to read type feedback for the RHS of an invalid assignment which full codegen never actually allocated info for.

To do: check properly in preparser already.

R=marja@chromium.org, mstarzinger@chromium.org
BUG=351658
LOG=Y

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19976 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-17 10:21:01 +00:00
marja@chromium.org
ee46e648ec Move ParseYieldExpression to ParserBase.
R=mstarzinger@chromium.org
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19921 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-14 09:51:22 +00:00
marja@chromium.org
a89f68c6cd Move ParseAssignmentExpression to ParserBase.
R=mstarzinger@chromium.org, mstarzinger
BUG=v8:3126
LOG=N

Committed: https://code.google.com/p/v8/source/detail?r=19908

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19920 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-14 09:43:04 +00:00
marja@chromium.org
7c66ec9319 Revert "Move ParseAssignmentExpression to ParserBase."
This reverts revision 19908.

Reason: clang doesn't like it.

BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19909 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-13 16:11:26 +00:00
marja@chromium.org
9cc39f5a66 Move ParseAssignmentExpression to ParserBase.
R=mstarzinger@chromium.org, mstarzinger
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19908 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-13 16:06:08 +00:00
dcarney@chromium.org
750ab88341 move remaining uses of scanner literals into scanner
R=marja@chromium.org

BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19880 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-13 08:29:31 +00:00
marja@chromium.org
df5ac19412 Parser / PreParser unification: Add docs.
R=rossberg@chromium.org, rossberg
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19861 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-12 19:15:17 +00:00
marja@chromium.org
0ba0330269 Follow-up to r19845 which suppresses syntax errors in presence of a stack overflow.
ReportUnexpectedToken already calls Traits::ReportMessageAt. If we're in Parser,
that already suppresses the syntax error. If we're in PreParser, we don't need
to suppress the syntax error (preparser errors don't go through Isolate, and
having both stack overflow and a syntax error present is handled correctly by
PreParserApi::PreParse).

R=mstarzinger@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19851 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-12 14:15:13 +00:00
dcarney@chromium.org
87e77085a6 Move most scanner buffer accesses into scanner.
R=marja@chromium.org

BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19849 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-12 14:03:25 +00:00
marja@chromium.org
534245c9a5 Move ParseArguments to ParserBase and add tests.
Notes:
- PreParser didn't produce "too_many_arguments"; now it does.
- The argument count in the error message was wrong; fixed it.

BUG=v8:3126
LOG=N
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-11 16:30:47 +00:00
marja@chromium.org
cf820126b9 Move ParseObjectLiteral to ParserBase.
BUG=v8:3126
LOG=N
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19805 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-11 15:40:41 +00:00
rossberg@chromium.org
8e3f3cee9e Eliminate extended mode, and other modes clean-up
- Merge LanguageMode and StrictModeFlag enums
- Make harmony-scoping depend only on strict mode
- Free some bits on the way
- Plus additional clean-up and renaming

R=ulan@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19800 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-11 14:41:22 +00:00
rossberg@chromium.org
3f702d4bf9 Mode clean-up pt 1: rename classic/non-strict mode to sloppy mode
R=mstarzinger@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19799 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-11 14:39:08 +00:00
marja@chromium.org
988d5fe509 Parser & preparser unification: make the ParseFunctionLiteral APIs the same.
R=mstarzinger@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19763 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-10 15:19:20 +00:00
marja@chromium.org
f524f51ea7 parser: fix build on solaris
`FS` is defined in `regset.h` on solaris and smartos.

BUG=
R=ulan@chromium.org, danno@chromium.org

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

Patch from Fedor Indutny <fedor.indutny@gmail.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19602 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-28 12:08:17 +00:00
marja@chromium.org
5b9465c2fc (Pre)Parser: Move ParseExpression and ParseArrayLiteral to ParserBase.
Notes:
- The functions already did the same thing -> no changes in logic.
- One less glue function needed now.

R=ulan@chromium.org
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19469 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-19 08:56:11 +00:00
marja@chromium.org
73c4a61848 (Pre)Parser: Simplify NewExpression handling (fixed).
Notes:
- We use simple recursion to keep track of how many "new" operators we have seen
  and where.
- This makes the self-baked stack class PositionStack in parser.cc unnecessary.
- Now the logic is also unified between Parser and PreParser.
- This is a fixed version of r19386.

R=ulan@chromium.org
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19417 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-17 15:40:51 +00:00
marja@chromium.org
0323bf9cd7 Revert "(Pre)Parser: Simplify NewExpression handling."
This reverts revision 19386.

Reason: Mozilla failures.

BUG=
TBR=ulan@chromium.org,marja@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19388 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-14 16:08:14 +00:00
marja@chromium.org
c532977da3 (Pre)Parser: Simplify NewExpression handling.
Notes:
- We use simple recursion to keep track of how many "new" operators we have seen
  and where.
- This makes the self-baked stack class PositionStack in parser.cc unnecessary.
- Now the logic is also unified between Parser and PreParser.
- It might have been a copy-paste artifact (ParseLeftHandSideExpression ->
  ParseMemberWithNewPrefixesExpression) that the logic was so complicated
  before.

R=ulan@chromium.org
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19386 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-14 15:33:10 +00:00
marja@chromium.org
cd50687b41 (Pre)Parser: Move ParsePrimaryExpression to ParserBase.
Notes:
- To be able to move the recursive descent functions to ParserBase one at a
time, we temporarily need routing functions from traits to Parser/PreParser,
since the recursive descent functions form a cyclic structure.
- PreParser used to always allow intrinsic syntax. After this CL, it depends on
allow_natives_syntax() which was already in ParserBase.
- This CL also decouples (Pre)ParserTraits better from (Pre)Parser, passing more
information as parameters, so that the Traits don't need to get it from
(Pre)Parser.
R=ulan@chromium.org
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19374 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-14 11:24:26 +00:00
marja@chromium.org
cad32c1917 (Pre)Parser: Move FunctionState, BlockState and Scope handling to ParserBase.
Notes:
- This removes Parser::FunctionState and PreParser::FunctionState and adds
ParserBase::FunctionState etc.
- Also the scope stacks and function state stacks are moved to ParserBase.
- PreParser::FunctionState didn't add and subtract
JSFunction::kLiteralsPrefixSize (unlike Parser::FunctionState). Since the
actual value of NextMaterializedLiteralIndex is not used in the Preparser,
this change is valid.
- Traits no longer need functions like is_classic_mode(), since now there is a
 unified way of getting the information from the FunctionState / Scope.

R=ulan@chromium.org
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19361 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-13 16:17:55 +00:00
svenpanne@chromium.org
ece3480b2d Removed unused field, making clang happy again.
R=marja@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19353 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-13 12:02:57 +00:00
marja@chromium.org
10ae9eb247 Refactor scope and function state tracking in (Pre)Parser.
Notes:
- PreParser::Scope was a weird combination of Parser::FunctionState and
  Scope. Split it into two (PreParser::FunctionState and PreParser::Scope). This
  is necessary for unifying the Parser and the PreParser.
- Scopes take care of language mode and tracking "with".
- FunctionStates take care of counting material literal indexes, properties
  etc. and tracking generators.
- PreParser::Scope::InsideWith was a hack to make a FunctionState-like object
  take care of tracking "with". It's now the responsibility fo PreParser::Scope
  and Scope.
- PreParser::ScopeType is unnecessarly, there is already a ScopeType enum in
v8globals.h.
- Renamed scope stack variables so that they're consistent in Parser and PreParser.
- Parser::FunctionState and Parser::BlockState had an unnecessary dependency to
  the Parser; they only need a couple of things from Parser. Broke the
  dependency.

R=ulan@chromium.org
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19319 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-12 12:02:07 +00:00
marja@chromium.org
cec4fb021b Move parenthesized_function_ to ParserBase.
This change is trivial (was probably overlooked when ParserBase was created).

R=yangguo@chromium.org
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19317 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-12 11:56:07 +00:00
marja@chromium.org
f59ac1cba5 Move ParseRegexpLiteral to ParserBase.
R=ulan@chromium.org
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19273 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-11 11:51:01 +00:00
marja@chromium.org
d74fd20fca Traitify ParserBase and move functions there.
(Second try, with fixes. First try: https://codereview.chromium.org/149913006/ )

The long-term goal is to move all recursive descent functions from Parser and
PreParser into ParserBase, but first they need to be unified.

Notes:
- The functions moved in this CL: ParseIdentifier, ParseIdentifierName,
ParseIdentifierNameOrGetOrSet, ParseIdentifierOrStrictReservedWord.
- IOW, this CL removes Parser::ParseIdentifier and PreParser::ParseIdentifier
and adds ParserBase::ParseIdentifier, etc.
- Error reporting used to require virtual funcs; now error reporting is moved to
the Traits too, and ParserBase no longer needs to be virtual.
- I had to move PreParser::Identifier out of the PreParser class, because
otherwise PreParserTraits cannot use it in a typedef.

BUG=v8:3126
LOG=N
R=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19265 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-11 09:35:32 +00:00
marja@chromium.org
d8b8628f39 Revert "Traitify ParserBase and move functions there."
This reverts commit r19230.

Reason: Build failures on NaCl.

BUG=
TBR=marja@chromium.org,mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19234 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-10 16:21:11 +00:00
marja@chromium.org
71a6d70d97 Traitify ParserBase and move functions there.
The long-term goal is to move all recursive descent functions from Parser and
PreParser into ParserBase, but first they need to be unified.

Notes:
- The functions moved in this CL: ParseIdentifier, ParseIdentifierName,
ParseIdentifierNameOrGetOrSet, ParseIdentifierOrStrictReservedWord.
- IOW, this CL removes Parser::ParseIdentifier and PreParser::ParseIdentifier
  and adds ParserBase::ParseIdentifier, etc.
- Error reporting used to require virtual funcs; now error reporting is moved to
  the Traits too, and ParserBase no longer needs to be virtual.
- I had to move PreParser::Identifier out of the PreParser class, because
otherwise PreParserTraits cannot use it in a typedef.

BUG=v8:3126
LOG=N
R=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19230 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-10 15:35:39 +00:00
marja@chromium.org
caa727711f Unify function parameter checking in PreParser and Parser.
This also makes the "delayed strict mode violations" mechanism in PreParser
unnecessary.

The attached tests didn't pass before this CL but now they do.

BUG=v8:3126
LOG=N
R=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19197 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-07 12:44:45 +00:00
marja@chromium.org
5788b34a16 Unify function name validation in Parser and PreParser.
BUG=3126
LOG=N
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19193 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-07 10:47:01 +00:00
marja@chromium.org
032999da4c Merge Parser::ReportUnexpectedToken and PreParser::ReportUnexpectedToken.
(I.e., move ReportUnexpectedToken to ParserBase.)

Because of the recent unifications, they now do the same thing.

BUG=
R=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19161 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-06 15:10:21 +00:00
marja@chromium.org
42ea494cd6 Redo r19140 with better efficiency.
Still relevant parts of the original commit message:

Unify paren handling in Parser and PreParser.

It is only needed in (Pre)Parser::ParseExpressionOrLabelledStatement for not
recognizing parenthesized identifiers as labels and in
(Pre)Parser::ParseSourceElements for not recognizing a parenthesized string as
directive prologue.

Parser Expressions don't keep track of whether they're parenthesized, so
PreParser Expressions shouldn't either.

BUG=3126
LOG=N
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19153 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-06 13:12:10 +00:00
marja@chromium.org
e6bc60c98d Revert "Unify paren handling in Parser and PreParser."
This reverts r19140.

Reason: Octane regression.

BUG=
TBR=verwaest@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19147 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-06 11:59:16 +00:00
marja@chromium.org
76646e88ed Unify paren handling in Parser and PreParser.
It is only needed in (Pre)Parser::ParseExpressionOrLabelledStatement for not
recognizing parenthesized identifiers as labels and in
(Pre)Parser::ParseSourceElements for not recognizing a parenthesized string as
directive prologue.

Parser Expressions don't keep track of whether they're parenthesized, so
PreParser Expressions shouldn't either.

In addition, add helper funcs for checking if an Expression is identifier or a
given identifier. (PreParser Expressions can do this.)

BUG=3126
LOG=N
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19140 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-06 10:30:02 +00:00
marja@chromium.org
931fae7d1c Follow-up to r19112.
There's only one error message for "eval" and "arguments", so no need to pass it
to PreParser::StrictModeIdentifierViolation.

BUG=3126
LOG=N
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19137 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-06 10:16:25 +00:00
marja@chromium.org
8150464209 Make strict more error messages about "eval" and "arguments" less specific.
We used to have error messages which provide context, like "Variable name may
not be eval or arguments in strict mode", but for other illegal words we only
have non-context specific error messages like "Unexpected reserved word".

Providing the context makes the code unnecessarily complex, since every
individual place must remember to check for eval or arguments. This CL produces
a unified error message ("Unexpected eval or arguments in strict mode"), and puts
the error reporting to (Pre)Parser::ParseIdentifier.

Notes:

- The module feature is so experimental, that I decided to not allow "eval" or
"arguments" as module-related identifiers in the strict mode (even though this
check wasn't there before).

- Unfortunately, there were some inconsistencies, since it was the
responsibility of the caller of ParseIdentifier to check "eval" and "arguments"
and some places didn't have the check for no good reason. This CL is supposed to
keep backward compatibility and *not* introduce any new errors.

- ECMA allows "eval" and "arguments" as labels even in strict mode. (Syntax:
"LabelledStatement: Identifier : Statement", and no strict mode restrictions on
Identifier are listed.)

- Tests which compare error message strings will fail, and need to be updated.

BUG=3126
LOG=N
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-05 16:26:48 +00:00
mstarzinger@chromium.org
b01a6a4e01 Remove deprecated "i::" prefix from the pre-parser.
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17208 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-15 08:57:36 +00:00
mstarzinger@chromium.org
bdc8c36ca0 Unify several checking methods between parser and pre-parser.
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17207 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-15 08:32:58 +00:00
mstarzinger@chromium.org
caf2884222 Introduce ParserBase for common code between parser and pre-parser.
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17202 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-14 16:46:51 +00:00
mstarzinger@chromium.org
00125f43f0 Remove deprecated v8::preparser namespace.
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17192 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-14 13:07:20 +00:00
mstarzinger@chromium.org
f878c1c359 Fix pre-parsing of 'use strict' directive after string literals.
R=ulan@chromium.org
TEST=mjsunit/regress/regress-parse-use-strict

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17164 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-11 14:03:54 +00:00
mstarzinger@chromium.org
63d8abb6c6 Unify and fix checkers for duplicate object literal properties.
R=ulan@chromium.org
TEST=preparser/duplicate-property,mjsunit/regress/regress-parse-object-literal

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17136 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-10 11:58:16 +00:00
mvstanton@chromium.org
fc95207750 Revert "Unify and fix checkers for duplicate object literal properties."
This reverts commit 12c68518bd2c74dc4e44d928c84c17f98ca63359.
(r17114)

R=mstarzinger@chromium.org
TBR=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-10 08:45:19 +00:00
mstarzinger@chromium.org
067a266426 Unify and fix checkers for duplicate object literal properties.
R=ulan@chromium.org
TEST=preparser/duplicate-property

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17114 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-04 16:58:01 +00:00
bmeurer@chromium.org
50f3a993e7 Fix compilation with recent MinGW64 versions.
Don't check for WIN32 define. Use V8_OS_* macros whenever
possible, and if not use _WIN32.

BUG=v8:2300
R=yangguo@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16380 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-08-28 08:35:04 +00:00
rossberg@chromium.org
83d9e6e7ee Add support for explicit octal and binary integer literals
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.8.3

ES6 extends the numeric literals to support explicit support
for binary and octal literals using the following syntax:

  0b10101
  0o777

This is currently behind the flag, --harmony-numeric-literals

BUG=2783
R=rossberg@chromium.org

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

Patch from Erik Arvidsson <arv@chromium.org>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15772 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-07-19 09:57:35 +00:00
wingo@igalia.com
1fb2f4b358 For-of statements do not permit initializers.
R=rossberg@chromium.org
BUG=v8:2720

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15082 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-12 12:37:44 +00:00
wingo@igalia.com
cb0d146862 Add initial parser support for harmony iteration
This commit adds initial parser support for harmony iteration.
Specifically, it will parse:

  for (x of y) {}
  for (let x of y) {}
  for (var x of y) {}

The semantics are still unimplemented.

TEST=mjsunit/harmony/for-of-syntax
BUG=v8:2214
R=rossberg@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14984 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-06 14:38:26 +00:00
mstarzinger@chromium.org
d71678676f Refactor parser mode configuration for correctness
This patch refactors the parser and preparser interface to be more
readable and type-safe.  It has no behavior changes.

Previously, parsers and preparsers were configured via bitfield called
parser_flags in the Parser constructor, and flags in
PreParser::PreParseProgram, ParserApi::Parse, and ParserApi::PreParse.
This was error-prone in practice: six call sites passed incorrectly
typed values to this interface (a boolean FLAG value, a boolean false
and a boolean true value).  None of these errors were caught by the
compiler because it's just an "int".

The parser flags interface was also awkward because it encoded a
language mode, but the language mode was only used to turn on harmony
scoping or not -- it wasn't used to actually set the parser's language
mode.

Fundamentally these errors came in because of the desire for a
procedural parser interface, in ParserApi.  Because we need to be able
to configure the parser in various ways, the flags argument got added;
but no one understood how to use the flags properly.  Also they were
only used by constructors: callers packed bits, and the constructors
unpacked them into booleans on the parser or preparser.

The solution is to allow parser construction, configuration, and
invocation to be separated.  This patch does that.

It passes the existing tests.

BUG=

Review URL: https://codereview.chromium.org/13450007
Patch from Andy Wingo <wingo@igalia.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14151 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-04-05 13:01:06 +00:00
mstarzinger@chromium.org
502063c4a7 Fix another set of build failures on Windows since r14116.
TBR=yangguo@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14118 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-04-02 18:09:40 +00:00
mstarzinger@chromium.org
2816f19680 Add parser support for generators.
This patchset begins by adding support for "yield", which is unlike other tokens
in JS. In a generator, whether strict or classic, it is a syntactic keyword.
In classic mode it is an identifier. In strict mode it is reserved.

This patch adds YIELD as a token to the scanner, and adapts the preparser and
parser appropriately. It also parses "function*", indicating that a function is
actually a generator, for both eagerly and lazily parsed functions.

Currently "yield" just compiles as "return".

BUG=v8:2355
TEST=mjsunit/harmony/generators-parsing

Review URL: https://codereview.chromium.org/12646003
Patch from Andy Wingo <wingo@igalia.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14116 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-04-02 17:34:59 +00:00
rossberg@chromium.org
3348b5c2b4 Allow lazy compilation (and thus optimisation) of functions inside eval.
For strict-mode eval, this requires _disabling_ lazy parsing of inner functions,
because we need to collect their free variables to do allocation for the
eval scope properly.

R=mstarzinger@chromium.org
BUG=v8:2315

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13161 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-12-07 10:35:50 +00:00
svenpanne@chromium.org
6aceff1fa9 Fixed preparser for try statement. Tiny cleanup.
BUG=v8:2109
TBR=jkummerow@chromium.org

Review URL: https://chromiumcodereview.appspot.com/10270007

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11468 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-04-30 13:04:08 +00:00
erik.corry@gmail.com
03cfc4363b Fix input and output to handle UTF16 surrogate pairs.
Review URL: https://chromiumcodereview.appspot.com/9600009

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11007 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-03-12 12:35:28 +00:00
fschneider@chromium.org
d1172448ad Make HashMap a template class to specify the allocation policy.
The old HashMap class had an explicit member to determine the allocation
policy. The template version matches the approach used already for
lists.

Cleanup some include dependencies and unnecessary forward declarations.

Cleanup some dead code from isolate.h and replace some HEAP macros
with GetHeap().
Review URL: https://chromiumcodereview.appspot.com/9372106

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10806 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-23 09:12:57 +00:00
rossberg@chromium.org
a0b287a3b1 Extend scanner with new Harmony module keywords (under flag).
R=mstarzinger@chromium.org
BUG=
TEST=

Review URL: https://chromiumcodereview.appspot.com/9352013

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10638 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-08 10:53:58 +00:00
erik.corry@gmail.com
b3e0761e38 Cosmetic changes ("set up" is a verb, "setup" is a noun).
Review URL: http://codereview.chromium.org/9139051

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10399 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-01-13 13:09:52 +00:00
lrn@chromium.org
ebccde15bc Don't preparse large files to find boundaries of lazy functions.
Instead use the preparser inline to parse only the lazy function
bodies.

This is still disabled for small files.
More measurements are needed to determine if lazy-compiling small
sources is worth it.

Review URL: http://codereview.chromium.org/8662037

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10066 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-25 09:36:31 +00:00
keuchel@chromium.org
1e9a7267ab Introduce extended mode.
This CL introduces a third mode next to the non-strict
(henceforth called 'classic mode') and 'strict mode'
which is called 'extended mode' as in the current
ES.next specification drafts. The extended mode is based on
the 'strict mode' and adds new functionality to it. This
means that most of the semantics of these two modes
coincide.

The 'extended mode' is entered instead of the 'strict mode'
during parsing when using the 'strict mode' directive
"use strict" and when the the harmony-scoping flag is
active. This should be changed once it is fully specified how the 'extended mode' is entered.

This change introduces a new 3 valued enum LanguageMode
(see globals.h) corresponding to the modes which is mostly
used by the frontend code. This includes the following
components:
* (Pre)Parser
* Compiler
* SharedFunctionInfo, Scope and ScopeInfo
* runtime functions: StoreContextSlot,
  ResolvePossiblyDirectEval, InitializeVarGlobal,
  DeclareGlobals

The old enum StrictModeFlag is still used in the backend
when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
* SetProperty runtime function, Delete builtin
* StoreIC and KeyedStoreIC
* StubCache

Review URL: http://codereview.chromium.org/8417035

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-24 15:17:04 +00:00