1. 30 Jan, 2019 1 commit
  2. 28 Jan, 2019 2 commits
  3. 25 Jan, 2019 2 commits
  4. 23 Jan, 2019 1 commit
  5. 22 Jan, 2019 2 commits
  6. 21 Jan, 2019 3 commits
  7. 18 Jan, 2019 1 commit
  8. 16 Jan, 2019 2 commits
  9. 15 Jan, 2019 1 commit
    • Toon Verwaest's avatar
      [parser] Give hoisting sloppy block functions a valid position · 8436715f
      Toon Verwaest authored
      A sloppy function in a block scope implicitily creates a var in the outer
      declaration scope if it's not blocked. The assignment created reads the local
      lexical declaration for the function. The reference introduced automatically
      takes part in NeedsHoleCheck, requiring the reference to have a valid position.
      Since the assignment will happen after the local declaration, we give the
      end_position() of the closure as the position of the reference, so hole checks
      can be omitted.
      
      Bug: chromium:917755
      Change-Id: Iee0e042b2463f97f05075f9eec09dac8c6eaf539
      Reviewed-on: https://chromium-review.googlesource.com/c/1408991Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58823}
      8436715f
  10. 14 Jan, 2019 1 commit
  11. 11 Jan, 2019 1 commit
  12. 10 Jan, 2019 1 commit
  13. 09 Jan, 2019 1 commit
  14. 08 Jan, 2019 2 commits
    • Toon Verwaest's avatar
      [parser] Disambiguate variables through expression-scope · f9529f6b
      Toon Verwaest authored
      Previously we'd always push variable proxies into the unresolved list of the
      current scope, and possibly delete them from the list later in case they end up
      being declarations. If variables become assigned, there were two ways to mark
      them as such: The preparser would marked the variables tracked on the
      PreParserExpression, and the parser would traverse the LHS AST to find and mark
      all variables.
      
      After this CL, if the scope already knows it's tracking declarations, the
      variables are never added to the unresolved list in the first place. If the
      scope is ambigous, it tracks the variable proxies on the side and only adds
      them to the unresolved list if they end up being references rather than
      declarations. The same list is now used to bulk mark all LHS variables as
      assigned; uniformely for both the parser and the preparser.
      
      In a next step we'll also use the scope to create declarations. That way we can
      stop tracking variables_ on PreParserExpression altogether.
      
      Change-Id: I6ada37006cc2e066731f29cd4ea314550fc7959f
      Reviewed-on: https://chromium-review.googlesource.com/c/1397669
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58629}
      f9529f6b
    • Sathya Gunasekaran's avatar
      [parser] Refactor class field declaration · 64c85cf4
      Sathya Gunasekaran authored
      Change-Id: Ieed2a202cbbceaad8a598d359fcbd02944edfdb4
      Reviewed-on: https://chromium-review.googlesource.com/c/1398685
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58605}
      64c85cf4
  15. 07 Jan, 2019 2 commits
  16. 21 Dec, 2018 2 commits
  17. 19 Dec, 2018 2 commits
  18. 18 Dec, 2018 1 commit
    • Toon Verwaest's avatar
      [parser] Replacing ExpressionClassifier with ExpressionScope that knows what it's tracking · d1b4e31b
      Toon Verwaest authored
      Since it's explicit what we're tracking, we can immediately throw errors in
      certain cases, and ignore irrelevant errors. We don't need to use the
      classifier itself to track "let let", since we know whether we're parsing a
      "let". Errors that were previously (almost) always accumulated are now
      immediately pushed to the scopes that care (parameter initialization errors).
      
      This CL drops avoiding allocation of classified errors, at least for now, but
      that doesn't affect performance anymore since we don't aggressively blacklist
      anymore. Classified errors are even less likely with the more precise approach.
      
      ParseAssignmentExpression doesn't introduce its own scope immediately, but
      reuses the outer scope.
      
      Rather than using full ExpressionClassifiers + Accumulate to separate
      expressions/patterns from each other while keeping track of the overall error
      state, this now uses an explicit AccumulationScope.
      
      When we parse (async) arrow functions we introduce new scopes
      that track that they may be (async) arrow functions.
      
      We track StrictModeFormal parameters in 2 different ways if it isn't
      immediately certain that it is a strict-mode formal error: Either directly on
      the (Pre)ParserFormalParameters, or on the NextArrowFunctionInfo in the case
      we're not yet certain that we'll have an arrow function. In the latter case we
      don't have a FormalParameter object yet, and we'll copy it over once we know
      we're parsing an arrow function. The latter works because it's not allowed to
      change strictness of a function with non-simple parameters.
      
      Design doc:
      https://docs.google.com/document/d/1FAvEp9EUK-G8kHfDIEo_385Hs2SUBCYbJ5H-NnLvq8M/
      
      Change-Id: If4ecd717c9780095c7ddc859c8945b3d7d268a9d
      Reviewed-on: https://chromium-review.googlesource.com/c/1367809
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58307}
      d1b4e31b
  19. 30 Nov, 2018 1 commit
  20. 26 Nov, 2018 2 commits
  21. 22 Nov, 2018 1 commit
  22. 21 Nov, 2018 1 commit
  23. 19 Nov, 2018 1 commit
  24. 12 Nov, 2018 1 commit
  25. 09 Nov, 2018 1 commit
  26. 07 Nov, 2018 1 commit
  27. 05 Nov, 2018 2 commits
  28. 31 Oct, 2018 1 commit