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
(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
Legacy const is changed so that a declaration declares a configurable, but non-writable, slot, and the initializer reconfigures it (when possible) to non-configurable non-writable. This avoids the need for "the hole" as marker value in JSContextExtensionObjects and GlobalObjects. Undefined is used instead.
BUG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/379893002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22379 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
1) Call DeserializeScopeChain only if it's going to do something
non-trivial. And we only need to internalize the AstValueFactory in those cases.
2) BufferedUtf16CharacterStream::FillBuffer doesn't need the length
argument. The length is always kBufferSize and the subclasses can just read it
(it's protected).
R=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/381613003
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22307 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
