Skip to content

V
V8
Switch branch/tag
  1. 08 Aug, 2019 1 commit
  3. 27 Jun, 2019 1 commit
  5. 11 Jun, 2019 1 commit
  7. 25 Jan, 2019 1 commit
  9. 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
  11. 12 Nov, 2018 1 commit
  13. 06 Nov, 2018 1 commit
  15. 05 Nov, 2018 1 commit
  17. 31 Oct, 2018 1 commit
  19. 14 May, 2018 1 commit
  21. 07 May, 2018 1 commit
  23. 28 Nov, 2017 1 commit
  25. 26 Oct, 2017 1 commit
  27. 15 Sep, 2017 1 commit
  29. 24 Aug, 2017 1 commit
  31. 16 Jun, 2017 1 commit
  33. 28 Feb, 2017 1 commit
  35. 29 Nov, 2016 1 commit
  37. 24 Nov, 2016 1 commit
  39. 21 Mar, 2016 1 commit
  41. 16 Mar, 2016 1 commit
  43. 08 Sep, 2015 1 commit
    • mstarzinger's avatar
      Use baseline code to compute message locations. · 819b40aa
      mstarzinger authored 
      This switches Isolate::ComputeLocation to use baseline code when
computing message locations. This unifies locations between optimized
and non-optimized code by always going through the FrameSummary for
location computation.

R=bmeurer@chromium.org
TEST=message/regress/regress-4266
BUG=v8:4266
LOG=n

Review URL: https://codereview.chromium.org/1331603002

Cr-Commit-Position: refs/heads/master@{#30635}
      819b40aa
  45. 13 Apr, 2015 1 commit
  47. 11 Jul, 2011 1 commit
  49. 23 Oct, 2008 1 commit