Skip to content

V
V8
Switch branch/tag
  1. 04 Jul, 2018 3 commits
  3. 21 Jun, 2018 2 commits
  5. 06 Jun, 2018 2 commits
  7. 18 May, 2018 1 commit
  9. 25 Apr, 2018 1 commit
  11. 08 Feb, 2018 1 commit
  13. 10 Jan, 2018 1 commit
  15. 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
  17. 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
  21. 29 Jun, 2017 1 commit
  23. 16 Jun, 2017 1 commit
  25. 12 Apr, 2017 1 commit
  27. 11 Apr, 2017 1 commit
  29. 14 Feb, 2017 1 commit
  31. 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
  33. 20 Jan, 2017 1 commit
  35. 10 Jan, 2017 1 commit
  37. 31 Oct, 2016 1 commit
  39. 28 Sep, 2016 1 commit
  41. 31 Aug, 2016 1 commit
  43. 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
  45. 10 May, 2016 1 commit
  47. 09 May, 2016 1 commit
  49. 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