1. 04 Jan, 2018 1 commit
  2. 12 Dec, 2017 3 commits
    • Georg Neis's avatar
      Reland "Fix "this" value in lazily-parsed module functions." · 585b39f5
      Georg Neis authored
      This is a reland of c3bd741e
      Original change's description:
      > Fix "this" value in lazily-parsed module functions.
      >
      > When preparsing top-level functions in a module, we didn't track
      > unresolved variables. Consequently, "this" ended up referencing
      > the global "this", which has the wrong value (in a module "this"
      > is supposed to be the undefined value).
      >
      > This patch fixes that. This also lets us stop forcing context
      > allocation of all variables in module scopes, which the patch
      > takes care of as well.
      >
      > Bug: chromium:791334
      > Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
      > Reviewed-on: https://chromium-review.googlesource.com/808938
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50025}
      
      TBR=adamk@chromium.org
      TBR=kozyatinskiy@chromium.org
      
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      
      Bug: chromium:791334
      Change-Id: I57acc7b84a345565b36cbb55924fa2ff9b449eec
      Reviewed-on: https://chromium-review.googlesource.com/822341
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50045}
      585b39f5
    • Michael Achenbach's avatar
      Revert "Fix "this" value in lazily-parsed module functions." · 62f09de9
      Michael Achenbach authored
      This reverts commit c3bd741e.
      
      Reason for revert: Breaks layout tests:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/20384
      
      Original change's description:
      > Fix "this" value in lazily-parsed module functions.
      > 
      > When preparsing top-level functions in a module, we didn't track
      > unresolved variables. Consequently, "this" ended up referencing
      > the global "this", which has the wrong value (in a module "this"
      > is supposed to be the undefined value).
      > 
      > This patch fixes that. This also lets us stop forcing context
      > allocation of all variables in module scopes, which the patch
      > takes care of as well.
      > 
      > Bug: chromium:791334
      > Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
      > Reviewed-on: https://chromium-review.googlesource.com/808938
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50025}
      
      TBR=adamk@chromium.org,marja@chromium.org,neis@chromium.org,kozyatinskiy@chromium.org
      
      Change-Id: I81f69334ed2ce104c00e6205d50001e4bdf07d15
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:791334
      Reviewed-on: https://chromium-review.googlesource.com/822258Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50036}
      62f09de9
    • Georg Neis's avatar
      Fix "this" value in lazily-parsed module functions. · c3bd741e
      Georg Neis authored
      When preparsing top-level functions in a module, we didn't track
      unresolved variables. Consequently, "this" ended up referencing
      the global "this", which has the wrong value (in a module "this"
      is supposed to be the undefined value).
      
      This patch fixes that. This also lets us stop forcing context
      allocation of all variables in module scopes, which the patch
      takes care of as well.
      
      Bug: chromium:791334
      Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
      Reviewed-on: https://chromium-review.googlesource.com/808938Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50025}
      c3bd741e
  3. 30 Nov, 2017 1 commit
  4. 27 Nov, 2017 1 commit
  5. 23 Nov, 2017 1 commit
  6. 25 Oct, 2017 1 commit
  7. 22 Oct, 2017 1 commit
  8. 19 Oct, 2017 1 commit
  9. 17 Oct, 2017 2 commits
  10. 16 Oct, 2017 2 commits
  11. 13 Oct, 2017 1 commit
  12. 05 Oct, 2017 1 commit
    • Marja Hölttä's avatar
      [parser] Skipping inner funcs: Fix hoisting. · f6f5bafe
      Marja Hölttä authored
      The catch variable is a special VAR-mode variable which is not in a declaration
      scope. Normally creating such a variable is not possible with DeclareVariable,
      but Parser bypasses it by calling DeclareLocal directly (which doesn't have the
      hoisting check).
      
      PreParser used to cut corners and declare the catch variable as a LET-mode
      variable to prevent hoisting.
      
      But since LET and VAR variables behave differently when deciding whether they
      block sloppy block function hoisting, that approach doesn't fly.
      
      BUG=v8:5516,chromium:771474
      
      Change-Id: Ic6f5f4996416c9fa59132725c8b0b6b570c72f48
      Reviewed-on: https://chromium-review.googlesource.com/700634
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48308}
      f6f5bafe
  13. 15 Sep, 2017 1 commit
  14. 14 Sep, 2017 1 commit
  15. 23 Aug, 2017 1 commit
  16. 22 Aug, 2017 2 commits
  17. 21 Aug, 2017 1 commit
  18. 18 Aug, 2017 2 commits
    • Ross McIlroy's avatar
      [Parsing] Remove parse-task support. · ef8baffa
      Ross McIlroy authored
      Parse tasks are not currently used, and will need to be changed significantly
      for background compilation, so we remove them for now.
      
      BUG=v8:6093,v8:5203
      
      Change-Id: I44559a94ecca85668f0117629d35aaa5f4075745
      Reviewed-on: https://chromium-review.googlesource.com/617140
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47446}
      ef8baffa
    • Adam Klein's avatar
      [ast] Save one pointer in most Function and Variable declaration node · 69b165db
      Adam Klein authored
      Currently, Declaration stores a Scope pointer to whichever Scope the
      declaration appeared in. This is used to disallow var declarations
      being hoisted over lexical declarations. For example:
      
        {
          let x;
          { var x; }
        }
      
      But in fact this is the only sort of case where storing the scope
      is required: for lexical declarations (including function declarations
      appearing in blocks), Declaration::scope() was always identical to
      Declaration::proxy()->var()->scope(). That is, only var declarations
      end up "nested" in this way.
      
      This patch adds a subclass of VariableDeclaration to store the Scope.
      Since the only thing that cares about that data is Scope analysis,
      this isn't treated as a distinct AstNode::NodeType from VariableDeclaration,
      leaving all AstVisitors untouched in the process.
      
      Also reworked the logic in Scope::CheckConflictingVarDeclarations() for
      clarity after making changes to accomodate the new code.
      
      Change-Id: I6ee4298700508ab9e28a76ddb8504bae68bc473f
      Reviewed-on: https://chromium-review.googlesource.com/619595
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47441}
      69b165db
  19. 16 Aug, 2017 1 commit
  20. 14 Aug, 2017 1 commit
  21. 12 Aug, 2017 1 commit
  22. 09 Aug, 2017 2 commits
  23. 26 Jul, 2017 1 commit
  24. 25 Jul, 2017 1 commit
  25. 14 Jul, 2017 1 commit
    • Caitlin Potter's avatar
      [async-await] desugar Await in BytecodeGenerator · 8b5b444a
      Caitlin Potter authored
      This includes several changes. From most to least interesting:
      
      - No longer implement AwaitExpressions using a do-expression.
      - Reduces frame-size of async generators by not allocating temporary
        variables to hold results of Await epxressions.
      - Streamline and reduce generated bytecodes for Await.
      - Debugger no longer emits a debug::kCallBreakLocation breakpoint for
      the JS-builtin call performed for Await, and instead only emits such
      a breakpoint if the operand of Await is actually a call.
      - Push fewer parameters to Await* builtins, using the receiver for the
        first parameter (possible now that the CallRuntime invocation not
        part of the AST).
      - Adds a new Await AST node. No new members or anything, but it seemed
        palatable to avoid having `if (is_await())` in a number of
        VisitSuspend functions.
      
      BUG=v8:5855, v8:5099, v8:4483
      R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org
      TBR=bmeurer@chromium.org
      
      Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf
      Reviewed-on: https://chromium-review.googlesource.com/558806
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46666}
      8b5b444a
  26. 12 Jul, 2017 1 commit
  27. 30 Jun, 2017 1 commit
  28. 26 Jun, 2017 1 commit
    • hans's avatar
      Make some functions that are hit during renderer startup available for inlining · 777da354
      hans authored
      This is towards closing the perf gap between the MSVC build (which uses link-
      time optimization) and Clang (where LTO isn't ready on Windows yet). We did
      a study (see bug) to see which non-inlined functions are hit a lot during render
      start-up, and which would be inlined during LTO. This should benefit performance
      in all builds which currently don't use LTO (Android, Linux, Mac) as well as
      the Win/Clang build.
      
      The binary size of chrome_child.dll increases by 2KB with this.
      
      BUG=chromium:728324
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng
      
      Review-Url: https://codereview.chromium.org/2950993002
      Cr-Commit-Position: refs/heads/master@{#46229}
      777da354
  29. 25 Jun, 2017 1 commit
  30. 23 Jun, 2017 1 commit
    • hans's avatar
      Make some functions that are hit during renderer startup available for inlining · d00d52be
      hans authored
      This is towards closing the perf gap between the MSVC build (which uses link-
      time optimization) and Clang (where LTO isn't ready on Windows yet). We did
      a study (see bug) to see which non-inlined functions are hit a lot during render
      start-up, and which would be inlined during LTO. This should benefit performance
      in all builds which currently don't use LTO (Android, Linux, Mac) as well as
      the Win/Clang build.
      
      The binary size of chrome_child.dll increases by 2KB with this.
      
      BUG=chromium:728324
      
      Review-Url: https://codereview.chromium.org/2950993002
      Cr-Commit-Position: refs/heads/master@{#46191}
      d00d52be
  31. 22 Jun, 2017 2 commits
  32. 13 Jun, 2017 1 commit