Skip to content

V
V8
Switch branch/tag
  1. 24 Feb, 2017 1 commit
  3. 22 Feb, 2017 1 commit
  5. 20 Feb, 2017 2 commits
  7. 17 Feb, 2017 1 commit
    • vabr's avatar
      Report unexpected lexical decl also without destructuring · 454816f0
      vabr authored 
      https://codereview.chromium.org/2694003002/ introduced
"SyntaxError: Lexical declaration cannot appear in a single-statement context"
for the case when let + desctructuring from a list happen.

As was pointed out in https://codereview.chromium.org/2694003002/#msg18, the
case without destructuring would also benefit from a better message: if a
single statement is expected and "let identifier = ..." is seen, the error is
indeed again that the lexical declaration is not a statement. However, the current
error is "Unexpected identifier", because the parser tries to accept "let" as
an identifier in an expression statement, and then gives up seeing the other
identifier after "let".

This CL ensures that the parser recognises the error properly and reports
accordingly. It also renames the existing test, which contains destructuring,
and adds the one with a non-destructuring lexical declaration.

BUG=v8:5686

Review-Url: https://codereview.chromium.org/2697193007
Cr-Commit-Position: refs/heads/master@{#43275}
      454816f0
  9. 16 Feb, 2017 11 commits
  11. 15 Feb, 2017 4 commits
    • caitp's avatar
      [async-iteration] add support for for-await-of loops in Async Functions · 76ab55e3
      caitp authored 
      When --harmony-async-iteration is enabled, it is now possible to
use the for-await-of loop, which uses the Async Iteration protocol
rather than the ordinary ES6 Iteration protocol.

the Async-from-Sync Iterator object is not implemented in this CL,
and so for-await-of loops will abort execution if the iterated object
does not have a Symbol.asyncIterator() method. Async-from-Sync
Iterators are implemented seperately in https://codereview.chromium.org/2645313003/

BUG=v8:5855, v8:4483
R=neis@chromium.org, littledan@chromium.org, adamk@chromium.org

Review-Url: https://codereview.chromium.org/2637403008
Cr-Commit-Position: refs/heads/master@{#43224}
      76ab55e3
    • Marja Hölttä's avatar
      [parser] Minor refactoring: parameter handling · e7ebb930
      Marja Hölttä authored 
      - Different places used is_simple to mean different things; renamed one.

- No need to do Scope::SetHasNoSimpleParameters multiple times.

- Normally we create VAR parameters with a name, or (for destructuring
  parameters), TEMPORARY parmeters with an empty name. *Except* for
  destructuring rest parameters; then we create VAR a parameter with an empty
  name. This CL makes the empty-named parameter TEMPORARY instead of VAR.

- This makes it clear that Parser::DeclareFormalParameters declares exactly
  those params which Parser::BuildParamerterInitializationBlock doesn't declare.

- This unification doesn't change any functionality, but it makes sense to do
  since I'll need to make PreParser emulate what Parser does; this way I don't
  need to emulate the weird behavior.

BUG=v8:5501

Change-Id: Ifa6c116bc5908f4e03a36e74f47558888d1582bd
Reviewed-on: https://chromium-review.googlesource.com/443106Reviewed-by: 's avatarDaniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43220}
      e7ebb930
    • vabr's avatar
      ParserBase should accept ESCAPED_STRICT_RESERVED_WORD as an identifier · e3d761d9
      vabr authored 
      ParserBase::is_any_identifier currently does not recognise
Token::ESCAPED_STRICT_RESERVED_WORD as an identifier. This seems different
from what ParserBase::ParseIdentifierName does, and also prevents
"l\u0065t", unlike "let", from becoming a label.

This CL extends is_any_identifier to also accept ESCAPED_STRICT_RESERVED_WORD.

BUG=v8:5692

Review-Url: https://codereview.chromium.org/2695973003
Cr-Commit-Position: refs/heads/master@{#43204}
      e3d761d9
    • vabr's avatar
      Remove dead ExpressionUnexpectedToken from parser-base.h · 8a54a471
      vabr authored 
      The method ExpressionUnexpectedToken is not referenced anywhere apart from its
definition. This CL removes it.

The association with the bug below is only through discovering the dead code
when working on a fix for that bug.

BUG=v8:5692

Review-Url: https://codereview.chromium.org/2688413009
Cr-Commit-Position: refs/heads/master@{#43203}
      8a54a471
  13. 14 Feb, 2017 1 commit
  15. 13 Feb, 2017 2 commits
  17. 11 Feb, 2017 1 commit
  19. 10 Feb, 2017 8 commits
  21. 09 Feb, 2017 1 commit
  23. 08 Feb, 2017 1 commit
  25. 07 Feb, 2017 6 commits