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
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
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
State of the art:
- Chromium doesn't do a separate preparsing phase any more.
- We start parsing with Parser, and when it sees a lazy function, it falls back
to PreParser for that function.
- The symbol data should contain symbols which are *outside* lazy functions.
- So Parser should always produce symbol data, and PreParser should never.
- Because it's this simple now, we don't need to keep track of "should
produce symbol data" (i.e., whether we're inside a lazy func or not).
R=ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/222123003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20707 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
