1. 08 Aug, 2018 1 commit
  2. 07 Aug, 2018 1 commit
  3. 31 Jul, 2018 1 commit
  4. 20 Jul, 2018 1 commit
  5. 16 Jul, 2018 1 commit
  6. 12 Jul, 2018 1 commit
  7. 11 Jul, 2018 1 commit
    • Leszek Swirski's avatar
      [modules] Make exported variable indices stable · e39b90f6
      Leszek Swirski authored
      A module's exported variables are assigned a cell index based on their
      order in the exported variable map. This map is keyed by the variable
      name, an AstRawString*.
      
      Unfortunately, these string pointers are not guaranteed to increase
      monotonically as variables are encountered, which means that this map
      isn't stable across parses. In particular, it can cause failures for
      setVariableValue if the parser is unlucky.
      
      This patch adds a custom comparator to these AstRawString* keyed maps,
      which is stable across parses.
      
      Change-Id: Ie6e88fc2d252d873de661d7fc5278feba3955727
      Reviewed-on: https://chromium-review.googlesource.com/1131503Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54379}
      e39b90f6
  8. 05 Jul, 2018 1 commit
  9. 04 Jul, 2018 2 commits
  10. 02 Jul, 2018 1 commit
  11. 26 Jun, 2018 1 commit
  12. 21 Jun, 2018 2 commits
  13. 18 Jun, 2018 4 commits
  14. 15 Jun, 2018 3 commits
  15. 14 Jun, 2018 3 commits
  16. 11 Jun, 2018 1 commit
  17. 29 May, 2018 1 commit
  18. 28 May, 2018 1 commit
  19. 24 May, 2018 1 commit
  20. 14 May, 2018 1 commit
  21. 04 May, 2018 1 commit
  22. 02 May, 2018 1 commit
    • Leszek Swirski's avatar
      Revert "[parser] Slice the source string where possible" · 18bc2856
      Leszek Swirski authored
      This reverts commit 2df5e7a7.
      
      Reason for revert: Mystery crashes https://bugs.chromium.org/p/chromium/issues/detail?id=838805
      
      Original change's description:
      > [parser] Slice the source string where possible
      > 
      > When internalizing string literals (for quoted strings or property names),
      > try to create a sliced string of the source string rather than allocating
      > a copy of the bytes.
      > 
      > This will not work for string literals that contain escapes (e.g. unicode
      > escapes), and currently does not support two-byte strings.
      > 
      > Bug: chromium:818642
      > Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
      > Reviewed-on: https://chromium-review.googlesource.com/1010282
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52898}
      
      TBR=marja@chromium.org,yangguo@chromium.org,jarin@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,verwaest@chromium.org
      
      Change-Id: I598b6668c43a3e843e2dd8e60852b2b2f3461954
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:818642
      Reviewed-on: https://chromium-review.googlesource.com/1039885
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52919}
      18bc2856
  23. 01 May, 2018 1 commit
  24. 13 Apr, 2018 1 commit
  25. 09 Apr, 2018 2 commits
  26. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored
      This reverts commit f9a2e24b.
      
      Reason for revert: gc stress failures not all fixed by follow up.
      
      Original change's description:
      > [cleanup] Refactor the Factory
      > 
      > There is no good reason to have the meat of most objects' initialization
      > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      > this CL changes the protocol between Heap and Factory to be AllocateRaw,
      > and all object initialization work after (possibly retried) successful
      > raw allocation happens in the Factory.
      > 
      > This saves about 20KB of binary size on x64.
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      > Reviewed-on: https://chromium-review.googlesource.com/959533
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52416}
      
      TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
      
      Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored
      There is no good reason to have the meat of most objects' initialization
      logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      this CL changes the protocol between Heap and Factory to be AllocateRaw,
      and all object initialization work after (possibly retried) successful
      raw allocation happens in the Factory.
      
      This saves about 20KB of binary size on x64.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      Reviewed-on: https://chromium-review.googlesource.com/959533
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  27. 05 Apr, 2018 1 commit
  28. 21 Mar, 2018 1 commit
  29. 14 Mar, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] re-implement template strings" · b8229612
      Caitlin Potter authored
      - Add a new bytecode for the ToString operation, replacing the old
      intrinsic call (currently does not collect type feedback).
      - Add a new AST node to represent TemplateLiterals, and avoid
      generating unnecessary ToString operations in some simple cases.
      - Use a single feedback slot for each string addition, because the
      type feedback should always be the same for each addition
      
      This seems to produce a very slight improvement on JSTests benchmarks
      and bench-ruben.js from v8:7415, and it's possible that type feedback
      for the ToString bytecode could provide more opportunities to eliminate
      the runtime call in TurboFan.
      
      Doesn't touch tagged templates
      
      [esnext] fix OOB read in ASTPrinter::VisistTemplateLiteral
      
      Fixes an error where TemplateLiteral printing in --print-ast
      would try to read an element beyond the length of a vector.
      
      BUG=v8:7415, chromium:820596
      R=adamk@chromium.org, gsathya@chromum.org, rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
      
      Change-Id: Ie56894f73a6445550a5f95f42160c4e29ab1da42
      Reviewed-on: https://chromium-review.googlesource.com/958408Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#51933}
      b8229612