Commit Graph

344 Commits

Author SHA1 Message Date
arv@chromium.org
74a0d0f373 Fix issue with numeric property names
We were not correctly treating 1.0 as 1, nor 1.20 as 1.2 in accessors.

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

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23321 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-08-22 14:40:38 +00:00
marja@chromium.org
77d06401ad Take ast node id counting away from Isolate.
When we're going to parse multiple scripts in parallel, we cannot have the
Isolate count the ast node ids.

Now the counter is stored in CompilationInfo instead. This is because we need to
add ast nodes after parsing too.

R=rossberg@chromium.org
BUG=

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23301 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-08-22 11:12:29 +00:00
marja@chromium.org
ad3a1a99d3 Refactor parser Checkpoints.
Why this is better:

1) Not needing an extra template parameter for Checkpoints ctors. This was
especially confusing since the template parameter was named Parser and Parser is
also used as a type name and is also a concrete type. This CL makes it clear
that ParserTraits::Checkpoint is consturcted with ParserBase<ParserTraits> -
that's the only sensemaking type for the ctor param anyway.

2) This CL makes ParserBase define a Checkpoint base class (which knows how
to create and restore a checkpoint with ParserBase) which
PreParserTraits::Checkpoint and ParserTraits::Checkpoint inherit, and not the
other way around.

This is a more intuitive way to implement the "base functionality + extending
it" concept than the previous solution. The previous solution was to allow
Traits to define a Checkpoint class and make ParserBase<Traits>::ParserCheckpoint
(which defines the base functionality) inherit from it.

3) This CL moves the Checkpoint class definitions out of the SomeTraits::Type
struct; SomeTraits::Type is supposed to be a collection of typedefs and not
contain anything else.

Checkpoints were introduced in r22925 ( https://codereview.chromium.org/443903003 ).

BUG=
R=wingo@igalia.com

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23266 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-08-21 09:22:08 +00:00
arv@chromium.org
88ee432497 Refactor ParseObjectLiteral
This extracts the parsing of the ObjectLiteralProperty into its own
function. This is in preparation for adding support for parsing classes.

BUG=None
LOG=Y
R=dslomov@chromium.org, marja@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23249 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-08-20 15:51:07 +00:00
dslomov@chromium.org
65ae6e92ab Parse 'super' keyword.
BUG=v8:3330
LOG=N
R=arv@chromium.org, marja@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23157 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-08-18 12:35:34 +00:00
wingo@igalia.com
7d7629562f Rewind additional parser state when reinterpreting arrow arguments
The new ParserCheckpoint mechanism resets some state, notably the
bailout ID counter but also some statement counters (only applicable
once we get "do" expressions) when we decide to reinterpret a comma
expression as arrow function arguments.

R=rossberg@chromium.org, marja@chromium.org
BUG=v8:3475
LOG=N

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22925 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-08-06 12:05:39 +00:00
wingo@igalia.com
e6d8031cbf Revert "Rewind additional parser state when reinterpreting arrow arguments"
This reverts r22906.

TBR=rossberg@chromium.org
BUG=

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22907 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-08-06 09:23:56 +00:00
wingo@igalia.com
87494a806a Rewind additional parser state when reinterpreting arrow arguments
The new ParserCheckpoint mechanism resets some state, notably the
bailout ID counter but also some statement counters (only applicable
once we get "do" expressions) when we decide to reinterpret a comma
expression as arrow function arguments.

R=marja@chromium.org, rossberg@chromium.org
BUG=v8:3475
LOG=N

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22906 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-08-06 09:06:57 +00:00
wingo@igalia.com
6b7f9dba84 yield* calls @@iterator on iterable
R=rossberg@chromium.org
BUG=v8:3422
LOG=N

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22872 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-08-05 13:17:49 +00:00
bmeurer@chromium.org
d07a2eb806 Rename ASSERT* to DCHECK*.
This way we don't clash with the ASSERT* macros
defined by GoogleTest, and we are one step closer
to being able to replace our homegrown base/ with
base/ from Chrome.

R=jochen@chromium.org, svenpanne@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-08-04 11:34:54 +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
vogelheim@chromium.org
a42612b4a7 Change ScriptCompiler::CompileOptions to allow for two 'cache' modes
(parser or code) and to be explicit about cache consumption or production
(rather than making presence of cached_data imply one or the other.)

Also add a --cache flag to d8, to allow testing the functionality.

-----------------------------
API change

Reason: Currently, V8 supports a 'parser cache' for repeatedly executing the same script. We'd like to add a 2nd mode that would cache code, and would like to let the embedder decide which mode they chose (if any).

Note: Previously, the 'use cached data' property was implied by the presence of the cached data itself. (That is, kNoCompileOptions and source->cached_data != NULL.) That is no longer sufficient, since the presence of data is no longer sufficient to determine /which kind/ of data is present.

Changes from old behaviour:

- If you previously didn't use caching, nothing changes.
Example:
  v8::CompileUnbound(isolate, source, kNoCompileOptions);

- If you previously used caching, it worked like this:

  - 1st run:
  v8::CompileUnbound(isolate, source, kProduceToCache);
  Then, source->cached_data would contain the
  data-to-be cached. This remains the same, except you
  need to tell V8 which type of data you want.
  v8::CompileUnbound(isolate, source, kProduceParserCache);

  - 2nd run:
  v8::CompileUnbound(isolate, source, kNoCompileOptions);
  with source->cached_data set to the data you received in
  the first run. This will now ignore the cached data, and
  you need to explicitly tell V8 to use it:
  v8::CompileUnbound(isolate, source, kConsumeParserCache);
-----------------------------

BUG=
R=marja@chromium.org, yangguo@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22431 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-16 12:18:33 +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
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
yangguo@chromium.org
4057ed91af Fix memory leak in Parser after r22314.
R=marja@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22317 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-10 11:34:14 +00:00
yangguo@chromium.org
339bc81390 Refactor ScriptData class for cached compile data.
R=marja@chromium.org, vogelheim@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22314 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-10 10:28:05 +00:00
yangguo@chromium.org
1aede5f400 Introduce code serializer/deserializer.
R=vogelheim@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22276 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-08 09:04:08 +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
marja@chromium.org
7717f2366f Handle "//# sourceURL" comments in the Parser instead of the JS.
BUG=v8:2948
LOG=N
R=svenpanne@chromium.org, yurys@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22137 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-02 07:01:31 +00:00
marja@chromium.org
570a0bf8f5 Parser: add usage counters for "use asm".
R=jochen@chromium.org
BUG=

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22093 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-30 13:35:16 +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
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
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
ulan@chromium.org
3fcda0e576 Make let variables fresh in each iteration of a for-loop.
BUG=v8:2198
LOG=N
TEST=mjsunit/harmony/block-for
R=rossberg@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21480 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-05-26 08:07:02 +00:00
marja@chromium.org
2fee5a16ee Parser: delay throwing errors.
This makes Parser a bit more independent of Isolate during the recursive descent
phase. That is necessary for making it possible to run Parser on a non-main
thread in the future.

Proof of concept CL for the the "Parser independent of Isolate" work is here:
https://codereview.chromium.org/231073002/

BUG=
R=rossberg@chromium.org

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

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21385 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-05-20 12:22:04 +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
marja@chromium.org
98cd283399 Remove symbol preparse data altogether.
Removing it seems to be a clear win on mobile: producing symbol data makes cold
parsing 20-30% slower, and having symbol data doesn't make warm parsing any
faster.

Notes:
- V8 used to produce symbol data, but because of a bug, it was never used until
recently. (See fix https://codereview.chromium.org/172753002 which takes the
symbol data into use again.)
- On desktop, warm parsing is faster if we have symbol data, and producing it
during cold parsing doesn't make parsing substantially slower. However, this
doesn't seem to be the case on mobile.
- The preparse data (cached data) will now contain only the positions of the
lazy functions.

BUG=
R=dcarney@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21146 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-05-05 14:55:13 +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
a43a63b110 Refactor ParseFunctionLiteral.
It was a pretty monstrous 500 line function.

R=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20752 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-15 08:29:24 +00:00
marja@chromium.org
d70f78827e Fail the compilation if the cached data is invalid.
R=svenpanne@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20703 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-14 07:35:46 +00:00
marja@chromium.org
069d783a91 Remove the PreCompile API and ScriptData.
The new compilation API (ScriptCompiler::Compile) can produce the same data, so
the separate precompilation phase is not needed. ScriptData is replaced by
ScriptCompiler::CachedData.

R=svenpanne@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20683 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-11 11:44:49 +00:00
marja@chromium.org
3d1a17c2ac Update tests to use the new compilation API + related fixes.
Esp. get rid of PreCompile in tests, as it's going to be removed.

Notes:
- The new compilation API doesn't have a separate precompilation phase, so there
is no separate way to check for errors except checking the compilation
errors. Removed some tests which don't make sense any more.
- test-api/Regress31661 didn't make sense as a regression test even before the
compilation API changes, because Blink doesn't precompile this short scripts. So
detecting this kind of errors (see crbug.com/31661 for more information) cannot rely
on precompilation errors.
- test-parsing/PreParserStrictOctal has nothing to do with PreParser, and the comment
about "forcing preparsing" was just wrong.
- test-api/PreCompile was supposed to test that "pre-compilation (aka
preparsing) can be called without initializing the whole VM"; that's no longer
true, since there's no separate precompilation step in the new compile
API. There are other tests (test-parsing/DontRegressPreParserDataSizes) which
ensure that we produce cached data.
- Updated tests which test preparsing to use PreParser directly (not via the
 preparsing API).
- In the new compilation API, the user doesn't need to deal with ScriptData
ever. It's only used internally, and needed in tests that test internal aspects
(e.g., modify the cached data before passing it back).
- Some tests which used to test preparse + parse now test first time parse +
  second time parse, and had to be modified to ensure we don't hit the
  compilation cache.

BUG=
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20511 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-04 12:36: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
eecaef41d9 PreParser fix: propagate reference erros properly.
For example, invalid left hand sides are reference errors. PreParser didn't use
to produce this error ever, so the code for propagating reference errors
properly was missing, and reference errors turned into syntax errors.

R=rossberg@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20408 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-01 14:17:43 +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
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
e9358fa9ce Increase the "local variables in a function" limit.
The limit was originally added to avoid having large user-controlled constants
(variable indexes) in the code generated by full-codegen.

History behind this change:

The original CL for adding the limit was https://codereview.chromium.org/7003030
and at that time, the limit was 32767.

Reason for adding the limit (in CL comments): "The motivation behind this change
is to avoid large user controlled constants in the code. The slot_operand used
in the IA32 full code generator uses a relative load where the local index is an
(negative) immediate."

The limit was then bumped to 65535 by https://codereview.chromium.org/10965063
and to 131071 by https://codereview.chromium.org/11099063.

R=dcarney@chromium.org, svenpanne@chromium.org, jkummerow@chromium.org, rossberg@chromium.org
BUG=v8:3205
LOG=Y

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20126 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-20 13:37:26 +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
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
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
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
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
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
9ec8e586dd Remove Parser::scanner(). There is already ParserBase::scanner().
R=ulan@chromium.org
BUG=v8:3126
LOG=N

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19376 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-14 12:13:33 +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
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
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
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
marja@chromium.org
2794955852 Tests for (pre)parse errors when "eval" and "arguments" are found in inappropriate places.
In addition:
- Fix a bug in parser discovered by the tests (prefix and postfix confused in an
error message); the preparser had it right.
- Unify the parser and preparser error locations when the name of a function is
"eval" or "arguments. Now both point to the name.

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

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-04 11:26:19 +00:00
marja@chromium.org
f62ef25c08 Revert "Tests for (pre)parse errors when "eval" and "arguments" are found in inappropriate places."
Reason: The fixed error message broke some tests.

This reverts r19050.

BUG=
TBR=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19053 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-04 10:00:36 +00:00
marja@chromium.org
9aa05b0997 Tests for (pre)parse errors when "eval" and "arguments" are found in inappropriate places.
In addition:
- Fix a bug in parser discovered by the tests (prefix and postfix confused in an
  error message); the preparser had it right.
- Unify the parser and preparser error locations when the name of a function is
  "eval" or "arguments. Now both point to the name.

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

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19050 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-02-04 09:47:30 +00:00
rossberg@chromium.org
0d906a8bdb Zonify types in compiler frontend
Clean up some zone/isolate handling in AST and its visitors on the way.

(Based on https://codereview.chromium.org/103743004/)

R=jkummerow@chromium.org, titzer@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18719 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-01-21 16:22:52 +00:00
yangguo@chromium.org
2a4be7067c Refactor the compiling pipeline.
Goals:
 - easier to read, more suitable identifiers.
 - better distinction between compiling optimized/unoptimized code
 - compiler does not install code on the function.
 - easier to add features (e.g. caching optimized code for osr).
 - remove unnecessary code.

R=titzer@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18409 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-12-23 14:30:35 +00:00
bmeurer@chromium.org
a1d339a389 Remove unused ParserMessage class.
R=bmeurer@chromium.org

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

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17613 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-11-11 08:07:37 +00:00
mstarzinger@chromium.org
acac89008d Defer allocation of constant literal properties.
This moves building of constant properties and elements arrays for all
materialized literals into the compiler. The parser no longer allocates
while parsing ObjectLiteral and ArrayLiteral expressions.

R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17557 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-11-07 12:08:37 +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
rossberg@chromium.org
19d716989e Unify handling of position info in AST, part 1
* AstNode now has a position info.
* Removed various ad-hoc position infos from subclasses (most of which had it).
* Position is always set with the constructor, instead of later.
* Take care to use kNoPosition in the right spots, to not crash the debugger.

Still to do:

* Eliminate Conditional::then/else_position and WhileStatement::condition_position.
* Make CaseClause a proper AstNode and eliminate its custom position.
* If possible, eliminate all uses of kNoPosition.

R=yangguo@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17183 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-14 09:24:58 +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
mstarzinger@chromium.org
191bcf20cc Limit entry points into the parser API.
R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-10-01 09:27:03 +00:00
dcarney@chromium.org
3e76d8b870 remove Isolate::Current from most files starting with 'o' through 'r'
R=svenpanne@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16513 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-09-04 07:05:11 +00:00
rossberg@chromium.org
971df386b3 Fix scoping of function declarations in eval inside non-trivial local scope
R=mstarzinger@chromium.org
BUG=v8:2594

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16286 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-08-23 09:25:37 +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
bmeurer@chromium.org
49b9ef269b Remove useless ZoneScopes from Parser.
R=danno@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15330 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-26 08:05:41 +00:00
svenpanne@chromium.org
6c879c8a30 Removed some useless/dead code regarding CompileTimeValues.
R=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15300 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-24 14:26:32 +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
b29a78fb02 Baseline for-of implementation
Add full-codegen support for the ES6 for-of iteration statement.

R=mstarzinger@chromium.org, rossberg@chromium.org
TEST=mjsunit/harmony/iteration-semantics
BUG=v8:2214

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15002 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-07 11:12:21 +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
rossberg@chromium.org
919d64adce Add type field to AST expression nodes
More importantly, do a bunch of renamings of incidental existing "types" to avoid actual and potential name clashes (and also to improve consistency).

R=svenpanne@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14978 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-06 13:28:22 +00:00
verwaest@chromium.org
5e8679beea Remove the optimized construct stub.
R=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14946 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-06-05 08:43:25 +00:00
wingo@igalia.com
467b16fd3a Remove unneeded argument from Parser::GetSymbol
Parser::GetSymbol can't actually fail, so no need for the bool* ok
argument or the CHECK_OK in callers.

BUG=
R=mstarzinger@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14727 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-05-21 10:45:58 +00:00
verwaest@chromium.org
52008429b7 Use mutable heapnumbers to store doubles in fields.
R=danno@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14597 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-05-08 15:02:08 +00:00
mstarzinger@chromium.org
591a8ec86c Calling a generator function returns a generator object
* src/heap.h:
* src/heap.cc:
* src/objects-debug.cc:
* src/objects-inl.h:
* src/objects-printer.cc:
* src/objects-visiting.cc:
* src/objects.cc:
* src/objects.h: Define a new object type, JSGeneratorObject.

* src/factory.h:
* src/factory.cc (NewFunctionFromSharedFunctionInfo): Generator function
  inital maps construct the new JS_GENERATOR_OBJECT_TYPE objects, not
  generic JSObjects.

* src/runtime.h:
* src/runtime.cc (Runtime_CreateJSGeneratorObject):
* src/arm/full-codegen-arm.cc (Generate):
* src/ia32/full-codegen-ia32.cc (Generate):
* src/x64/full-codegen-x64.cc (Generate): Before visiting generator
  bodies, arrange to construct and return a generator object.

* test/mjsunit/harmony/generators-objects.js: Add tests for the
  properties and prototype of generator objects.

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

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

Patch from Andy Wingo <wingo@igalia.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14264 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-04-15 12:29:44 +00:00
mstarzinger@chromium.org
1345caa208 Devirtualize Parser
* src/parser.h: No one inherits from Parser, so the destructor can be
  non-virtual, removing the need for Parser to have a vtable. Also add
  BASE_EMBEDDED to it and to RegExpParser.

BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14162 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-04-08 11:53:50 +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
7e0ae6da66 Fix bogus uses of preparser API
* src/api.cc (ScriptData::PreCompile): Fix bogus use of bogus value for
  preparsing flags by removing those arguments, which were always zero.

* src/parser.h
* src/parser.cc (ParserApi::PreParse): Remove extension and flags
  arguments, both of which were either always 0 or incorrectly used.

* test/cctest/test-parsing.cc (RegressChromium62639, Regress928): Fix
  more bogus uses of preparser api.

BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14140 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-04-04 14:34:19 +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
verwaest@chromium.org
37a2e32496 Unify kMaxArguments with number of bits used to encode it.
Increase the number of bits by 1 by making Flags unsigned.

BUG=chromium:211741

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13964 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-03-18 13:35:17 +00:00
danno@chromium.org
5a40f006f9 Remove unused private member variables found by clang -Wunused-private-field
Review URL: https://codereview.chromium.org/11414207
Patch from Adam Klein <adamk@chromium.org>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13096 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-11-29 15:13:49 +00:00
rossberg@chromium.org
00132da734 Bump variable limit further to 2^17.
R=jkummerow@chromium.org
BUG=151625

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12698 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-10-11 11:40:10 +00:00
rossberg@chromium.org
b07f38a46b Reject local module declarations.
R=mstarzinger@chromium.org
BUG=150628

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12665 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-10-05 09:14:08 +00:00
rossberg@chromium.org
20b1c426cf Bump number of allowed variables per scope to 65535, to address GWT.
R=jkummerow@chromium.org
BUG=151625

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12600 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-09-24 16:22:17 +00:00
rossberg@chromium.org
a6e45ce7b8 Introduce some predicates over variable modes.
These should be handy when we add more declaration forms for Harmony.

R=svenpanne@chromium.org
BUG=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12404 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-08-29 09:19:53 +00:00
mstarzinger@chromium.org
fa2287fa96 Force eager compilation of parenthesized functions.
This makes the compiler use eager compilation for function literals that
are parenthesized. We consider this to be a hint that the function will
be called immediatly and hence try to avoid parsing it twice. The parser
already respects this heuristic.

R=ulan@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12270 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-08-07 14:47:36 +00:00
mstarzinger@chromium.org
6744e6e9a6 Remove obsolete ParserApi::PartialPreParse method.
R=yangguo@chromium.org

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12103 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-07-17 11:31:05 +00:00
rossberg@chromium.org
ec042177d7 Incorporate constness into inferred interfaces
(in preparation for handling imports).

R=svenpanne@chromium.org
BUG=v8:1569
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12078 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-07-13 09:29:43 +00:00
rossberg@chromium.org
98db1a369d Implement proper module linking.
Specifically:

- In parser, check that all exports are defined.
- Move JSModule allocation from parser to scope resolution.
- Move JSModule linking from full codegen to scope resolution.
- Implement module accessors for exported value members.
- Allocate module contexts statically along with JSModules
  (to allow static linking), but chain them when module literal is evaluated.
- Make module contexts' extension slot refer to resp. JSModule
  (makes modules' ScopeInfo accessible from context).
- Some other tweaks to context handling in general.
- Make any code containing module literals (and thus embedding
  static references to JSModules) non-cacheable.

This enables accessing module instance objects as expected.
Import declarations are a separate feature and do not work yet.

R=mstarzinger@chromium.org
BUG=v8:1569
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-07-09 08:59:03 +00:00
sanjoy@chromium.org
6fef6e451c Unbreak bleeding_edge by getting the Parser to work with a CompilationInfo instead of a Handle<Script> and a Zone. This should have been fixed in the initial patch itself but escaped my attention.
BUG=
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11878 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-06-20 10:56:53 +00:00
sanjoy@chromium.org
9e4fbb45c1 One Zone per CompilationInfo.
The CompilationInfo record now saves a Zone, and the compiler pipeline
allocates memory from the Zone in the CompilationInfo.  Before
compiling a function, we create a Zone on the stack and save a pointer
to that Zone to the CompilationInfo; which then gets picked up and
allocated from.

BUG=
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11877 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-06-20 08:58:41 +00:00
sanjoy@chromium.org
6125718f37 Remove TLS access for current Zone.
By passing around a Zone object explicitly we no longer need to do a
TLS access at the sites that allocate memory from the current Zone.

BUG=
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11761 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-06-11 12:42:31 +00:00
sanjoy@chromium.org
98db16d94f Progress towards making Zones independent of Isolates and Threads.
This CL changes some parts of the code to explicitly pass around a
Zone.  Not passing in a zone is okay too (in fact most of v8 still
doesn't), but that may incur a TLS lookup.

BUG=
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11709 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-06-04 14:42:58 +00:00
mstarzinger@chromium.org
79a98de9f7 Fix declarations escaping global strict eval.
According to ES5 10.4.2(3), eval calls of strict code always require
their own lexical and variable environment. For now we just add a new
scope when we parse the strict mode directive. The clean solution would
be to always have this sope present (even for global eval calls) and
adapt variable binding to cope with that.

R=rossberg@chromium.org
BUG=v8:1624
TEST=mjsunit/regress/regress-1624,test262/S10.4.2.1_A1

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11057 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-03-15 13:02:21 +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
rossberg@chromium.org
448b620dad Basic interface inference for modules.
All module expressions, and all variables that might refer to modules,
are assigned interfaces (module types) that are resolved using
unification. This is necessary to deal with the highly recursive
nature of ES6 modules, which does not allow any kind of bottom-up
strategy for resolving module names and paths.

Error messages are rudimental right now. Probably need to track
more information to make them nicer.

R=svenpanne@chromium.org
BUG=v8:1569
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10966 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-03-08 13:03:07 +00:00
rossberg@chromium.org
b89c0a962c AST extensions and parsing for import & export declarations.
R=jkummerow@chromium.org
BUG=
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10866 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-29 12:12:52 +00:00
rossberg@chromium.org
d809d17f5d Further refactoring of declarations in the AST:
Define modules as module declarations.
Separate function declarations from var declarations.

R=jkummerow@chromium.org
BUG=
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10854 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-28 10:12:39 +00:00
rossberg@chromium.org
958b3bf470 Parsing of basic module declarations (no imports/exports yet).
Module definitions are not compiled or otherwise executed yet.
Toplevel module identifiers are bound but never initialized.

R=kmillikin@chromium.org,mstarzinger@google.com
BUG=
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10759 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-20 14:02:59 +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
jkummerow@chromium.org
d795b7c620 Collect AstNode type information
Review URL: https://chromiumcodereview.appspot.com/9221011

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10631 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-02-08 09:56:33 +00:00
erik.corry@gmail.com
70da367f6b More spelling changes.
Review URL: http://codereview.chromium.org/9231009

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10407 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2012-01-16 12:38:59 +00:00
keuchel@chromium.org
08b4262512 Statically check for assignments to const in harmony mode.
The ES.next draft rev 4 in section 11.13 reads:
It is a Syntax Error if the AssignmentExpression is contained in extended code
and the LeftHandSideExpression is an Identifier that does not statically resolve
to a declarative environment record binding or if the resolved binding is an
immutable binding.

This CL adds corresponding static checks for the immutable binding case.

TEST=mjsunit/harmony/block-const-assign

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10156 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-12-05 14:43:28 +00:00
keuchel@chromium.org
b3a2e242db Reapply "Fix the ScopeIterator reimplementation".
This reapplies a fixed version of r10076 that also works on arm. Patch set one is r10076 reapplied and patch set 2 contains the new fix.

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10080 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-29 08:43:14 +00:00
keuchel@chromium.org
9664e48e14 Revert r10076 due to arm build failures.
Review URL: http://codereview.chromium.org/8716005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10077 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-28 14:01:13 +00:00
keuchel@chromium.org
8866d63cc9 The ScopeIterator uses recorded scope position - as detailed in scopes.h - and
source code positions it gets from the program counter to recreate the scope
chain by reparsing the function or program.

This CL includes the following changes
* Adds source code positions for the assignment added by the rewriter.
* Run the preparser over global code first.
* Use the ScopeType from the ScopeInfo to determine if the code being debugged
  is eval, function or global code instead of looking up the '.result' symbol.

TEST=mjsunit/debug-stepout-scope.js

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10076 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-28 12:47:39 +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
cbf08248f7 Make the parser track the language mode instead of keeping its own harmony flag.
So far the parser had its own harmony flag to disable the harmony scoping
feature when parsing native functions. With the introduction of the extended
language mode this becomes unnecessary because native functions will never enter
the extended mode. The parser can thus track FLAG_harmony_scoping and the
language mode of the current scope to see if harmony features are allowed. The
scanner and preparser have to keep their flag, because they can't use
FLAG_harmony_scoping as it is not available for the preparser-process
executable.

This depends on:
http://codereview.chromium.org/8417035/

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10063 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-24 15:58:09 +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
yangguo@chromium.org
6551e8d47d Removing exit time destructors by leaking static members.
Note that some cctests and d8 still contain statical members with exit time destructors.

BUG=v8:1828

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10025 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-18 08:59:33 +00:00
keuchel@chromium.org
08c9629f80 Static resolution of outer variables in eval code.
So far free variables references in eval code are not statically
resolved. For example in
    function foo() { var x = 1; eval("y = x"); }
the variable x will get mode DYNAMIC and y will get mode DYNAMIC_GLOBAL,
i.e. free variable references trigger dynamic lookups with a fast case
handling for global variables.

The CL introduces static resolution of free variables references in eval
code. If possible variable references are resolved to bindings belonging to
outer scopes of the eval call site.

This is achieved by deserializing the outer scope chain using
Scope::DeserializeScopeChain prior to parsing the eval code similar to lazy
parsing of functions. The existing code for variable resolution is used,
however resolution starts at the first outer unresolved scope instead of
always starting at the root of the scope tree.

This is a prerequisite for statically checking validity of assignments in
the extended code as specified by the current ES.next draft which will be
introduced by a subsequent CL. More specifically section 11.13 of revision 4
of the ES.next draft reads:
* It is a Syntax Error if the AssignmentExpression is contained in extended
  code and the LeftHandSideExpression is an Identifier that does not
  statically resolve to a declarative environment record binding or if the
  resolved binding is an immutable binding.

TEST=existing tests in mjsunit

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9999 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-15 13:48:40 +00:00
kmillikin@chromium.org
e49d533b50 Reapply "Add a level of indirection to exception handler addresses."
Original commit message:

Add a level of indirection to exception handler addresses.

To support deoptimization of exception handlers, the handler address in the
stack is converted to a pair of code object and an index into a separate
table of code offsets.  The index part is invariant under deoptimization.
The index is packed into the handler state field so that handler size does
not change.

R=vegorov@chromium.org
BUG=
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9977 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-11 13:48:14 +00:00
kmillikin@chromium.org
66ff8828a0 Revert "Add a level of indirection to exception handler addresses."
This reverts r9975.  This change broke (at least) snapshots on x64.

TBR=fschneider@chromium.org
BUG=
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9976 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-11 13:13:35 +00:00
kmillikin@chromium.org
1635117db9 Add a level of indirection to exception handler addresses.
To support deoptimization of exception handlers, the handler address in the
stack is converted to a pair of code object and an index into a separate
table of code offsets.  The index part is invariant under deoptimization.
The index is packed into the handler state field so that handler size does
not change.

R=vegorov@chromium.org,fschneider@chromium.org
BUG=
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9975 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-11 12:51:42 +00:00
kmillikin@chromium.org
7664133e87 A small collection of cleanup in the parser and AST.
* Remove a couple of unused fields from the FunctionLiteral, ensure that all
  the bools are packed.
* Rename SaveScope and LexicalScope in the parser.
* Use an enum to generate the numbers 0..N and the dependent count, rather
  than static const ints.  This is simpler to extend (coming in a future
  change).

R=danno@chromium.org,keuchel@chromium.org
BUG=
TEST=

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

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9933 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2011-11-09 13:54:26 +00:00