1. 16 May, 2016 1 commit
  2. 29 Apr, 2016 1 commit
  3. 18 Mar, 2016 1 commit
  4. 15 Jan, 2016 1 commit
  5. 26 Nov, 2015 1 commit
  6. 17 Nov, 2015 1 commit
  7. 16 Nov, 2015 1 commit
  8. 30 Sep, 2015 1 commit
  9. 28 Aug, 2015 1 commit
    • littledan's avatar
      Sloppy-mode let parsing · decc7b09
      littledan authored
      This patch makes 'let' a contextual keyword in both strict and sloppy mode.
      It behaves as a keyword when used at the beginning of a StatementListItem
      or lexical declaration at the beginning of a for statement, if it is followed
      by an identifier, [ or {. Implementing this change requires an extra token
      look-ahead by the parser which is only invoked in certain cases (so as to
      avoid parsing RegExps as ECMAScript tokens). This might result in a slowdown
      of the scanner, but performance testing of this patch hasn't yet found much
      of a regression.
      
      BUG=v8:3305
      LOG=Y
      R=adamk,vogelheim
      
      Review URL: https://codereview.chromium.org/1315673009
      
      Cr-Commit-Position: refs/heads/master@{#30451}
      decc7b09
  10. 03 Mar, 2015 1 commit
  11. 04 Feb, 2015 1 commit
    • marja's avatar
      Introduce LanguageMode, drop StrictMode. · c7851da4
      marja authored
      This enables adding more language modes in the future.
      
      For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to
      use a sequence of language modes which are progressively stricter, but we can
      express the language mode as combination of features.
      
      For now, LanguageMode can only be "sloppy" or "strict", and there are
      STATIC_ASSERTS in places which need to change when more modes are added.
      
      LanguageMode is a bit like the old LanguageMode when "extended" mode was still
      around (see https://codereview.chromium.org/8417035 and
      https://codereview.chromium.org/181543002 ) except that it's transmitted through
      all the layers (there's no StrictModeFlag).
      
      BUG=
      
      Review URL: https://codereview.chromium.org/894683003
      
      Cr-Commit-Position: refs/heads/master@{#26419}
      c7851da4
  12. 30 Jan, 2015 1 commit
  13. 14 Nov, 2014 1 commit
  14. 29 Sep, 2014 1 commit
  15. 16 Sep, 2014 1 commit
  16. 18 Aug, 2014 1 commit
  17. 04 Aug, 2014 1 commit
  18. 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
  19. 11 Jul, 2014 1 commit
  20. 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
  21. 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
  22. 30 Jun, 2014 1 commit
  23. 03 Jun, 2014 1 commit
  24. 29 Apr, 2014 1 commit
  25. 11 Mar, 2014 1 commit
  26. 02 Dec, 2013 1 commit
  27. 25 Jul, 2013 1 commit
  28. 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
  29. 13 Feb, 2013 1 commit
  30. 05 Nov, 2012 1 commit
  31. 02 Mar, 2012 1 commit
  32. 24 Feb, 2012 1 commit
  33. 08 Feb, 2012 1 commit
  34. 25 Oct, 2011 1 commit
  35. 19 Sep, 2011 1 commit
    • svenpanne@chromium.org's avatar
      Unify the handling of comparinsons against null and undefined. · cf63503c
      svenpanne@chromium.org authored
      Although this patch is not small, most parts of it are rather mechanical:
      
       * First of all, the concept of a 'nil-like' value is introduced, which can be
         null or undefined. They are treated symmetrically regarding comparisons, so
         it makes sense to handle them in a uniform manner. It is a mystery why
         JavaScript defines two of those beasts, when even *one* is a design wart...
      
       * Extended and renamed a few things which now handle undefined in addition to
         null.
      
       * Made the parts of the full code generator and the hydrogen generation which
         deal with comparisons a bit more similar regarding their handling of special
         cases.
      
       * Refactored the syntactical detection of special cases for comparisons,
         hopefully making them a bit more readable and less copy-n-paste-oriented.
         Things like this should really be a one-liner in any sane programming
         language... :-P
      
       * Cut down the length of the argument lists of a few functions to something
         less insane, making them more easily understandable locally. This involves
         minor code duplication, but this was a good tradeoff and can be remedied
         later if necessary.
      
       * Replaced some boolean arguments with more readable enums.
      
       * Fixed a TODO: Values which are definitely a Smi or unboxed can never be equal
         to null or undefined.
      Review URL: http://codereview.chromium.org/7918012
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9323 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      cf63503c
  36. 30 Aug, 2011 1 commit
  37. 16 Aug, 2011 1 commit
  38. 09 Aug, 2011 1 commit
  39. 24 Jun, 2011 1 commit