Skip to content

V
V8
Switch branch/tag
  1. 18 Aug, 2014 1 commit
  3. 04 Aug, 2014 1 commit
  5. 14 Jul, 2014 1 commit
    • marja@chromium.org's avatar
      Implement handling of arrow functions in the parser · 70da8959
      marja@chromium.org authored 
      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
      70da8959
  7. 11 Jul, 2014 1 commit
  9. 10 Jul, 2014 1 commit
    • marja@chromium.org's avatar
      Implement handling of arrow functions in the parser · e5991fc3
      marja@chromium.org authored 
      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
      e5991fc3
  11. 08 Jul, 2014 2 commits
    • marja@chromium.org's avatar
      Revert "Implement handling of arrow functions in the parser" · c393b9a5
      marja@chromium.org authored 
      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
      c393b9a5
    • marja@chromium.org's avatar
      Implement handling of arrow functions in the parser · 7367720d
      marja@chromium.org authored 
      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
      7367720d
  13. 02 Jul, 2014 1 commit
  15. 30 Jun, 2014 1 commit
  17. 24 Jun, 2014 1 commit
  19. 18 Jun, 2014 1 commit
  21. 13 Jun, 2014 1 commit
  23. 03 Jun, 2014 1 commit
  25. 27 May, 2014 1 commit
  27. 26 May, 2014 2 commits
  29. 05 May, 2014 1 commit
  31. 29 Apr, 2014 1 commit
  33. 13 Mar, 2014 2 commits
  35. 12 Mar, 2014 1 commit
  37. 10 Feb, 2014 1 commit
  39. 07 Feb, 2014 2 commits
  41. 10 Oct, 2013 2 commits
  43. 04 Oct, 2013 1 commit
  45. 19 Jul, 2013 1 commit
  47. 11 Jun, 2013 1 commit
  49. 06 Jun, 2013 1 commit
  51. 16 Apr, 2013 1 commit
  53. 05 Apr, 2013 1 commit
    • mstarzinger@chromium.org's avatar
      Refactor parser mode configuration for correctness · d7167867
      mstarzinger@chromium.org authored 
      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
      d7167867
  55. 02 Apr, 2013 1 commit
    • mstarzinger@chromium.org's avatar
      Add parser support for generators. · 2816f196
      mstarzinger@chromium.org authored 
      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
      2816f196
  57. 09 Jan, 2013 1 commit
  59. 03 Jan, 2013 1 commit
  61. 20 Dec, 2012 1 commit
  63. 16 Apr, 2012 1 commit
  65. 12 Mar, 2012 1 commit
  67. 08 Feb, 2012 1 commit
  69. 25 Nov, 2011 1 commit