Skip to content

V
V8
Switch branch/tag
  1. 11 Sep, 2018 1 commit
  3. 05 Sep, 2018 2 commits
  5. 29 Aug, 2018 2 commits
  7. 28 Aug, 2018 1 commit
  9. 26 Feb, 2018 1 commit
  11. 06 Feb, 2018 1 commit
  13. 17 Jan, 2018 1 commit
  15. 29 Nov, 2017 1 commit
    • Georg Neis's avatar
      No longer desugar the exponentiation (**) operator. · b97567a9
      Georg Neis authored 
      Prior to this change, the exponentiation operator was rewritten by the
parser to a call of the Math.pow builtin. However, Math.pow does not
accept BigInt arguments, while the exponentiation operator must accept
them.

This CL
- removes the parser's special treatment of ** and **=, treating them
  like any other binary op instead.
- adds a TFC builtin Exponentiate that does the right thing for
  all inputs.
- adds interpreter bytecodes Exp and ExpSmi whose handlers call the
  Exponentiate builtin. For simplicity, they currently always collect
  kAny feedback.
- adds a Turbofan operator JSExponentiate with a typed-lowering to
  the existing NumberPow and a generic-lowering to the Exponentiate
  builtin. There is currently no speculative lowering.

Note that exponentiation for BigInts is actually not implemented yet,
so we can't yet test it.

Bug: v8:6791
Change-Id: Id90914c9c3fce310ce01e715c09eaa9f294f4f8a
Reviewed-on: https://chromium-review.googlesource.com/785694Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49696}
      b97567a9
  17. 25 Oct, 2017 1 commit
  19. 17 Oct, 2017 1 commit
  21. 13 Oct, 2017 2 commits
  23. 09 Oct, 2017 1 commit
  25. 16 Aug, 2017 1 commit
  27. 28 Jun, 2017 1 commit
  29. 22 May, 2017 1 commit
  31. 28 Mar, 2017 1 commit
    • Daniel Vogelheim's avatar
      [parser] Introduce 'contextual keyword tokens'. · ae1e8759
      Daniel Vogelheim authored 
      Introduce 'contextual keyword' tokens, which are parsed as identifiers but
in some contexts are treated by the parser like proper keywords. These are
usually keywords introduced by recent ECMAScript versions, which for reasons
of backwards compatibility are still permissible as regular identifiers in
most contexts.

Current usage is to check for Token::IDENTIFIER and then do a string
compare. With this change the initial scan will scan them as usual, but
will then record the token as IDENTIFIER plus a secondary token with the
'contextual' value.

BUG=v8:6902

Change-Id: I6ae390382998cf756a23720bd481cb9c0eb78a72
Reviewed-on: https://chromium-review.googlesource.com/459479
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44189}
      ae1e8759
  33. 22 Aug, 2016 1 commit
  35. 17 Aug, 2016 1 commit
    • vogelheim's avatar
      Scanner::LiteralBuffer usage cleanup. · c677f813
      vogelheim authored 
      1, restrict use of LiteralBuffers to the tokens that actually need it.
  - E.g., previously the Token::FUNCTION would have a literal buffer
    containing "function", which was never actually used.
  - This eliminates copies of the string data for every call to
    PeekAhead or SetBookmark.
2, document & enforce the "secret" Scanner API contract w/ DCHECK
  - Document & check the correspondence of token value and literal buffer.
  - Document & check preconditions for calling PeekAhead, ScanRegExp*,
    ScanTemplate*.

BUG=v8:4947

Review-Url: https://codereview.chromium.org/2240513003
Cr-Commit-Position: refs/heads/master@{#38677}
      c677f813
  37. 16 May, 2016 1 commit
  39. 29 Apr, 2016 1 commit
  41. 18 Mar, 2016 1 commit
  43. 15 Jan, 2016 1 commit
  45. 26 Nov, 2015 1 commit
  47. 17 Nov, 2015 1 commit
  49. 16 Nov, 2015 1 commit
  51. 30 Sep, 2015 1 commit
  53. 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
  55. 03 Mar, 2015 1 commit
  57. 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
  59. 30 Jan, 2015 1 commit
  61. 14 Nov, 2014 1 commit
  63. 29 Sep, 2014 1 commit
  65. 16 Sep, 2014 1 commit
  67. 18 Aug, 2014 1 commit
  69. 04 Aug, 2014 1 commit
  71. 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
  73. 11 Jul, 2014 1 commit