1. 24 Jun, 2020 1 commit
  2. 19 Dec, 2019 1 commit
    • Shu-yu Guo's avatar
      Remove per-parameter position var scope · 1b450a17
      Shu-yu Guo authored
      The spec was normatively changed to simplify var scopes for parameter
      expressions. Previously there was a per-parameter var scope in sloppy
      mode so direct evals could introduce vars that did not escape the
      parameter position. That semantics is complex both for the programmer
      and implementation and has resulted in bugs in the past. Furthermore, it
      has never been fully interoperable (with Safari in particular). The spec
      was instead changed to be simpler: to have a single var scope for
      sloppy evals in parameters that encloses the parameter scope and body
      scope.
      
      This simplification lets us remove expression-scope-reparenter.
      
      Drive-by removal of stale reference to PatternRewriter.
      
      Bug: v8:7532
      Change-Id: Iade5594abe0009f7f3f6a1adad18628b17e1e779
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962471Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65517}
      1b450a17
  3. 29 Jan, 2019 1 commit
  4. 14 Jan, 2019 1 commit
  5. 08 Jan, 2019 1 commit
  6. 21 Dec, 2018 1 commit
  7. 20 Dec, 2018 1 commit
  8. 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
  9. 06 Dec, 2018 1 commit
    • tzik's avatar
      Replace %RunMicrotasks with %PerformMicrotaskCheckpoint · 07011cc4
      tzik authored
      This replaces Runtime_RunMicrotasks with Runtime_PerformMicrotaskCheckpoint.
      
      RunMicrotasks forcibly runs Microtasks even when the microtasks are suppressed,
      and may causes nested Microtasks in a problematic way. E.g. that confuses
      v8::MicrotasksScope::IsRunningMicrotasks() and GetEnteredOrMicrotaskContext().
      
      OTOH, PerformMicrotaskCheckpoint() doesn't run cause the failure as it
      respects the microtask suppressions.
      
      As all existing tests don't call RunMicrotasks() in the suppressed situation
      (like Promise.resolve().then(()=>{%RunMicrotasks();})), this change should
      not affect to these tests.
      
      Change-Id: Ib043a0cc8e482e022d375084d65ea98a6f54ef3d
      Reviewed-on: https://chromium-review.googlesource.com/c/1360095Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58068}
      07011cc4
  10. 04 Jul, 2018 3 commits
  11. 21 Jun, 2018 2 commits
  12. 06 Jun, 2018 2 commits
  13. 18 May, 2018 1 commit
  14. 25 Apr, 2018 1 commit
  15. 08 Feb, 2018 1 commit
  16. 10 Jan, 2018 1 commit
  17. 20 Dec, 2017 1 commit
    • Caitlin Potter's avatar
      [builtins] abort FrameFunctionIterator::next if frame summary empty · 18dc491c
      Caitlin Potter authored
      Previously, FrameFunctionIterator::next() assumed that the frame summary
      was non-empty. It's now possible for the list not to be empty, if the
      JS microtask pump invokes a builtin function which uses
      FrameFunctionIterator directly. While this is unlikely to show up in
      real world code, it is necessary to handle it to prevent crashes.
      
      BUG=chromium:794744
      R=mstarzinger@chromium.org, cbruni@chromium.org, verwaest@chromium.org
      
      Change-Id: Ie95c2228544f57730d1c6c1ff955b2c94ff1c06b
      Reviewed-on: https://chromium-review.googlesource.com/833266Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#50221}
      18dc491c
  18. 25 Jul, 2017 1 commit
  19. 30 Jun, 2017 1 commit
    • Mathias Bynens's avatar
      [elements] Rename FAST elements kinds · 26c00f4a
      Mathias Bynens authored
      The `FAST_` prefix doesn’t make much sense — they’re all just different cases
      with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
      vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.
      
      This patch renames the FAST elements kinds as follows:
      
      - e.g. FAST_ELEMENTS => PACKED_ELEMENTS
      - e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS
      
      The following exceptions are left intact, for lack of a better name:
      
      - FAST_SLOPPY_ARGUMENTS_ELEMENTS
      - SLOW_SLOPPY_ARGUMENTS_ELEMENTS
      - FAST_STRING_WRAPPER_ELEMENTS
      - SLOW_STRING_WRAPPER_ELEMENTS
      
      This makes it easier to reason about elements kinds, and less confusing to
      explain how they’re used.
      
      R=jkummerow@chromium.org, cbruni@chromium.org
      BUG=v8:6548
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
      Reviewed-on: https://chromium-review.googlesource.com/556032Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46361}
      26c00f4a
  20. 29 Jun, 2017 1 commit
  21. 16 Jun, 2017 1 commit
  22. 12 Apr, 2017 1 commit
  23. 11 Apr, 2017 1 commit
  24. 14 Feb, 2017 1 commit
  25. 10 Feb, 2017 1 commit
    • caitp's avatar
      [async-await] (simpler) fix for Return in try/finally in async functions · 39642fa2
      caitp authored
      Alternative approach to https://codereview.chromium.org/2667983004/, which
      does not depend on implicit control flow changes from
      https://codereview.chromium.org/2664083002
      
      - Remove handling for `async function` from Parser::RewriteReturn(). This functionality
      is moved to BytecodeGenerator::BuildAsyncReturn(). This ensures that promise resolution
      is deferred until all finally blocks are evaluated fully.
      
      - Add a new deferred command (CMD_ASYNC_RETURN), which instructs ControlScope to
      generate return code using BuildAsyncReturn rather than BuildReturn.
      
      - Parser has a new `NewReturnStatement()` helper which determines what type of return
      statement to generate based on the type of function.
      
      BUG=v8:5896, v8:4483
      R=littledan@chromium.org, neis@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, gsathya@chromium.org
      
      Review-Url: https://codereview.chromium.org/2685683002
      Cr-Commit-Position: refs/heads/master@{#43104}
      39642fa2
  26. 20 Jan, 2017 1 commit
  27. 10 Jan, 2017 1 commit
  28. 31 Oct, 2016 1 commit
  29. 28 Sep, 2016 1 commit
  30. 31 Aug, 2016 1 commit
  31. 29 Aug, 2016 1 commit
    • littledan's avatar
      Disallow tail calls from async functions and generators · 5af4cd98
      littledan authored
      Tail calls don't make sense from async functions and generators, as
      each activation of these functions needs to make a new, distnict,
      non-reused generator object. These tail calls are not required per
      spec. This patch disables both syntactic and implicit tail calls
      in async functions and generators.
      
      R=neis
      BUG=v8:5301,chromium:639270
      
      Review-Url: https://codereview.chromium.org/2278413003
      Cr-Commit-Position: refs/heads/master@{#38986}
      5af4cd98
  32. 10 May, 2016 1 commit
  33. 09 May, 2016 1 commit
  34. 04 May, 2016 1 commit
    • ishell's avatar
      [es8] More spec compliant syntactic tail calls implementation. · 1350eb3d
      ishell authored
      Unlike previous implementation where the 'continue' keyword was a feature of a return statement the keyword is now recognized as a part of expression. Error reporting was significantly improved.
      
      --harmony-explicit-tailcalls option is now orthogonal to --harmony-tailcalls so we can test both modes at the same time.
      
      This CL also adds %GetExceptionDetails(exception) that fetches hidden |start_pos| and |end_pos| values from the exception object.
      
      BUG=v8:4915
      LOG=N
      
      Review-Url: https://codereview.chromium.org/1928203002
      Cr-Commit-Position: refs/heads/master@{#36024}
      1350eb3d