1. 29 Aug, 2019 1 commit
    • Leszek Swirski's avatar
      [scopes] Push sloppy eval check through eval scopes · f6057ff1
      Leszek Swirski authored
      Sloppy eval extends the outer declaration scope's context. This is also
      true for sloppy eval inside of other sloppy evals -- the outer declaration
      scope's context is extended rather than the outer sloppy eval's
      declaration scope. However, we consider eval scopes to also be declaration
      scopes, for the purposes of strict eval and caching lookup variables. So,
      we need to make sure that we skip through sloppy eval scopes when marking
      a scope as calls_sloppy_eval.
      
      In fact, we implement this rather as never marking sloppy eval scopes as
      calls_sloppy_eval, under the assumption that the parent scope will already
      have been marked calls_sloppy_eval by the outer eval.
      
      As a drive-by, fix a TODO to move this logic from calls_sloppy_eval() to
      RecordEvalCall(), rename the variable to something more meaningful, and
      make Snapshotting to use a new calls_eval bit on Scope.
      
      Bug: chromium:996751
      Change-Id: I27ccc7ef429a7ce60b3bb02bf64a3820ae4a2c36
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773247
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63455}
      f6057ff1
  2. 23 Aug, 2019 1 commit
  3. 11 Jun, 2019 1 commit
  4. 24 May, 2019 1 commit
  5. 23 May, 2019 1 commit
  6. 21 May, 2019 1 commit
  7. 15 May, 2019 1 commit
  8. 11 Apr, 2019 1 commit
  9. 26 Feb, 2019 1 commit
    • Toon Verwaest's avatar
      [preparser] Split GetSymbol into GetSymbol and GetIdentifier · acfe5921
      Toon Verwaest authored
      GetSymbol previously always internalized the underlying string, even if the
      preparser does not need it. The most common case where this isn't needed is
      property name parsing. This seems to speed up preparsing quite a bit.
      
      For future reference: Property names in object literals still are needed due to
      various checks (e.g., get 'constructor', duplicate __proto__, ...); as well as
      cover grammar parsing (property names can turn into variable references). If we
      turn all strings that the preparser needs to identify back into contextual
      keywords we may be able to avoid the former.
      
      Change-Id: I549e4600053de3136ca08d4915cc04db36d66a89
      Reviewed-on: https://chromium-review.googlesource.com/c/1488764Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59866}
      acfe5921
  10. 15 Feb, 2019 1 commit
  11. 30 Jan, 2019 1 commit
  12. 23 Jan, 2019 1 commit
  13. 22 Jan, 2019 2 commits
  14. 21 Jan, 2019 2 commits
  15. 18 Jan, 2019 1 commit
  16. 15 Jan, 2019 1 commit
  17. 11 Jan, 2019 2 commits
  18. 10 Jan, 2019 1 commit
  19. 09 Jan, 2019 1 commit
  20. 08 Jan, 2019 2 commits
    • Camillo Bruni's avatar
      [parser] Avoid processing empty preparse data objects · 9cd84510
      Camillo Bruni authored
      Always precheck that the PreparseData has data before serializing it.
      
      Drive-by-fix:
      - rename preparsed_scope_data_builder_ to preparse_data_builder_
      
      Change-Id: I8e709af8f69db44e03caa9132f06a7b8c906bfdb
      Reviewed-on: https://chromium-review.googlesource.com/c/1387305Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58635}
      9cd84510
    • 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
  21. 07 Jan, 2019 2 commits
  22. 21 Dec, 2018 1 commit
  23. 19 Dec, 2018 3 commits
  24. 18 Dec, 2018 3 commits
    • Camillo Bruni's avatar
      [parsing] Always stack-allocate DataGatheringScopes · 8c3369f9
      Camillo Bruni authored
      Avoiding malloc and unique_ptr seems to have positive effects on a
      representative facebook and cnn workload.
      This makes arrow functions and eager functions potentially more
      expensive since the DataGatheringScope is now always stack-allocated
      and only the full initialization happens conditionally.
      
      Change-Id: Ibf1c1308a7db464f7c5d2bafd61560e4cabf0ce9
      Reviewed-on: https://chromium-review.googlesource.com/c/1382733Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58340}
      8c3369f9
    • Toon Verwaest's avatar
      [parser] Detect duplciate lexical declarations in preparser · dde5e3a1
      Toon Verwaest authored
      This changes how rewind upon preparser abort works. It now rewinds to the start
      of the parameter scope. In the case of "function X(" it is before the "(". In
      the case of arrow functions it's before the start of the arrow function. This
      allows us to reparse the arrow function from the start so all parameters are
      declared properly.
      
      Bug: v8:2728, v8:7390
      Change-Id: I1c40056a49ec198560e63cd73949a59221ee0401
      Reviewed-on: https://chromium-review.googlesource.com/c/1382736Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58332}
      dde5e3a1
    • 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
  25. 30 Nov, 2018 1 commit
  26. 27 Nov, 2018 1 commit
  27. 22 Nov, 2018 1 commit
  28. 14 Nov, 2018 1 commit
  29. 13 Nov, 2018 2 commits
  30. 12 Nov, 2018 1 commit