1. 31 Jul, 2017 1 commit
  2. 25 Jul, 2017 1 commit
  3. 14 Jul, 2017 2 commits
    • Caitlin Potter's avatar
      [generators] remove SuspendFlags enum and related code · 53553f5d
      Caitlin Potter authored
      SuspendFlags was originally used by the suspend operation to determine
      which field to record the bytecode offset of a suspended generator, and
      the value the generator was resumed with. For async generators, await
      operations would use a separate field, in order to preserve the previous
      yield input value. This was important to ensure `function.sent`
      continued to function correctly.
      
      As function.sent is being retired, this allows the removal of support
      for that. Given that this was the only real need for SuspendFlags in the
      first place (with other uses tacked on as a hack), this involves several
      other changes as well:
      
      - Modification of MacroAssembler AssertGeneratorObject. No longer
        accepts a SuspendFlags parameter to determine which type of check to
        perform.
      - Removal of `flags` operand from SuspendGenerator bytecode, and the
        GeneratorStore js-operator.
      - Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
      - Removal of Runtime functions, interpreter intrinsics and
        AccessBuilders associated with the [[await_input_or_debug_pos]] field
        in JSAsyncGeneratorObject, as this field no longer exists.
      - Addition of a new `Yield` AST node (subclass of Suspend) in order to
        prevent the need for the other SuspendFlag values.
      
      BUG=v8:5855
      TBR=bmeurer@chromium.org
      
      Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
      Reviewed-on: https://chromium-review.googlesource.com/570485
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46683}
      53553f5d
    • 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
  4. 06 Jul, 2017 1 commit
  5. 30 Jun, 2017 1 commit
  6. 23 Jun, 2017 1 commit
  7. 19 Jun, 2017 1 commit
  8. 15 Jun, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [parser] Better error message when destructuring against undefined/null · bc2c785c
      Sathya Gunasekaran authored
      Previously, when destructuring against null or undefined we would
      print:
      
        d8> var { x } = null
        (d8):1: TypeError: Cannot match against 'undefined' or 'null'.
        var { x } = null
        ^
        TypeError: Cannot match against 'undefined' or 'null'.
            at (d8):1:1
      
      
      The above message uses the term "match" which isn't a common term in
      JavaScript to describe destructuring. This message also doesn't
      provide the name of the property that fails destructuring.
      
      This patch changes the error message to be:
      
        d8> var { x } = null;
        (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
        var { x } = null;
              ^
        TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
            at (d8):1:1
      
      This patch changes the message to say "destructure" instead of "match".
      
      This patch adds support for printing property names that are string
      literals. We iterate through every property and pick the first string
      literal property name if it exists. This provides at least some
      feedback to the developer.
      
      This patch also makes the pointer point to the position of the
      property name that fails destructuring.
      
      For computed and numeric property names, we print a generic error:
        d8> var { 1: x } = null
        (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'.
        var { 1: x } = null
        ^
        TypeError: Cannot destructure against 'undefined' or 'null'.
            at (d8):1:1
      
      Bug: v8:6499
      Change-Id: I35b1ac749489828686f042975294b9926e2dfc53
      Reviewed-on: https://chromium-review.googlesource.com/537341Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45965}
      bc2c785c
  9. 30 May, 2017 1 commit
    • Aleksey Kozyatinskiy's avatar
      [inspector] moved var initialization break location before init expression (reland) · fb6a094d
      Aleksey Kozyatinskiy authored
      This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position.
      Benefits (see test for details):
       - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2),
       - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}.
       
      TBR=dgozman@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org,devtools-reviews@chromium.org,v8-reviews@googlegroups.com
      # Not skipping CQ checks because original CL landed > 1 day ago.
      Bug: v8:5909
      
      Change-Id: Ie84fa79afeed09e28cf8478ba610a0cfbfdfc294
      Reviewed-on: https://chromium-review.googlesource.com/518116
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45598}
      fb6a094d
  10. 29 May, 2017 1 commit
    • Michael Achenbach's avatar
      Revert "[inspector] moved var initialization break location before init expression" · ee1db48c
      Michael Achenbach authored
      This reverts commit 7a9cc704.
      
      Reason for revert: Changes layout tests:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/15882
      
      This is about:
      inspector/sources/debugger/source-frame-inline-breakpoint-decorations.html
      
      Original change's description:
      > [inspector] moved var initialization break location before init expression
      > 
      > This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position.
      > Benefits (see test for details):
      > - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2),
      > - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}.
      > 
      > Bug: v8:5909
      > Change-Id: I039d911903a2826c9859710a63ab0462c992e11b
      > Reviewed-on: https://chromium-review.googlesource.com/513926
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45530}
      
      TBR=dgozman@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org
      # Not skipping CQ checks because original CL landed > 1 day ago.
      Bug: v8:5909
      
      Change-Id: Ibf84401e8050d3c84db219d983de2c6bba0f697f
      Reviewed-on: https://chromium-review.googlesource.com/518102Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45547}
      ee1db48c
  11. 25 May, 2017 1 commit
  12. 11 Apr, 2017 1 commit
    • gsathya's avatar
      [ESNext] Implement DynamicImportCall · 94283dcf
      gsathya authored
      This patch implements the runtime semantics of dynamic import.
      
      We create a new ASTNode so that we can pass the JSFunction closure() to
      the runtime function from which we get the script_url.
      
      d8 implements the embedder logic required to load and evaluate the modules.
      
      The API is mostly implemented as specified.
      
      BUG=8:5785
      
      Review-Url: https://codereview.chromium.org/2703563002
      Cr-Commit-Position: refs/heads/master@{#44551}
      94283dcf
  13. 22 Mar, 2017 1 commit
  14. 15 Feb, 2017 1 commit
  15. 10 Feb, 2017 1 commit
  16. 07 Feb, 2017 3 commits
  17. 01 Feb, 2017 1 commit
    • adamk's avatar
      [parser] Remove hoist_scope from DeclarationDescriptor · 59b8496c
      adamk authored
      The hoist_scope member of DeclarationDescriptor was only used to pass the function
      scope for declaration of parameters containing sloppy evals, for example:
      
        function f(x = eval("var y")) { }
      
      In cases like this, "x" is declared in the function scope but "y" is declared in an inner scope.
      Rather than passing the function scope as "hoist_scope", we simply ask for the outer_scope()
      of the inner scope as needed in PatternRewriter.
      
      This reduces the cognitive overhead of understanding what a DeclarationDescriptor has; for
      example, it removes some dead code from the PreParser which never has to deal
      with a situation like the example above.
      
      Review-Url: https://codereview.chromium.org/2662183002
      Cr-Commit-Position: refs/heads/master@{#42861}
      59b8496c
  18. 31 Jan, 2017 1 commit
  19. 30 Jan, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Combine the literals array and the feedback vector. · 93f05b64
      mvstanton authored
      They have the same lifetime. It's a match!
      
      Both structures are native context dependent and dealt with (creation,
      clearing, gathering feedback) at the same time. By treating the spaces used
      for literal boilerplates as feedback vector slots, we no longer have to keep
      track of the materialized literal count elsewhere.
      
      A follow-on CL removes even more parser infrastructure related to this count.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2655853010
      Cr-Commit-Position: refs/heads/master@{#42771}
      93f05b64
  20. 21 Jan, 2017 1 commit
  21. 18 Jan, 2017 2 commits
  22. 17 Jan, 2017 1 commit
  23. 10 Jan, 2017 1 commit
  24. 09 Jan, 2017 1 commit
  25. 08 Dec, 2016 1 commit
    • neis's avatar
      [parsing] Fix maybe-assigned flag in some cases. · fcb75915
      neis authored
      This CL attempts to set the maybe-assigned flag for variables that are written
      to as part of a destructuring or loop header.
      
      For instance, in the following two cases we now mark x as maybe-assigned.
      
      a) [x] = [1];
      b) for (x of [1,2,3]) {};
      
      There's more work to do here, this is just a first step.
      
      R=adamk@chromium.org, mstarzinger@chromium.org
      BUG=v8:5636
      
      Review-Url: https://codereview.chromium.org/2562443003
      Cr-Commit-Position: refs/heads/master@{#41582}
      fcb75915
  26. 07 Dec, 2016 1 commit
    • caitp's avatar
      [ignition] desugar GetIterator() via bytecode rather than via AST · b5f146a0
      caitp authored
      Introduces:
      - a new AST node representing the GetIterator() algorithm in the specification, to be used by ForOfStatement, YieldExpression (in the case of delegating yield*), and the future `for-await-of` loop proposed in http://tc39.github.io/proposal-async-iteration/#sec-async-iterator-value-unwrap-functions.
      - a new opcode (JumpIfJSReceiver), which is useful for `if Type(object) is not Object` checks which are common throughout the specification. This node is easily eliminated by TurboFan.
      
      The AST node is desugared specially in bytecode, rather than manually when building the AST. The benefit of this is that desugaring in the BytecodeGenerator is much simpler and easier to understand than desugaring the AST.
      
      This also reduces parse time very slightly, and allows us to use LoadIC rather than KeyedLoadIC, which seems to have  better baseline performance. This results in a ~20% improvement in test/js-perf-test/Iterators micro-benchmarks, which I believe owes to the use of the slightly faster LoadIC as opposed to the KeyedLoadIC in the baseline case. Both produce identical optimized code via TurboFan when the type check can be eliminated, and the load can be replaced with a constant value.
      
      BUG=v8:4280
      R=bmeurer@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, neis@chromium.org, jarin@chromium.org
      TBR=rossberg@chromium.org
      
      Review-Url: https://codereview.chromium.org/2557593004
      Cr-Commit-Position: refs/heads/master@{#41555}
      b5f146a0
  27. 24 Nov, 2016 1 commit
  28. 23 Nov, 2016 2 commits
  29. 27 Oct, 2016 1 commit
  30. 25 Oct, 2016 1 commit
  31. 07 Oct, 2016 1 commit
  32. 19 Sep, 2016 1 commit
  33. 07 Sep, 2016 1 commit
  34. 02 Sep, 2016 1 commit
  35. 31 Aug, 2016 1 commit
    • adamk's avatar
      Remove CONST_LEGACY VariableMode · 7516fe1e
      adamk authored
      The only remaining use of this VariableMode is for the names of sloppy
      named function expressions. This patch instead uses CONST for such
      bindings (just as we do in strict mode) and instead marks those
      Variables specially. During code generation a new helper method,
      Variable::throw_on_const_assignment(), is called to decide whether
      to throw or silently ignore the assignment.
      
      Review-Url: https://codereview.chromium.org/2233673003
      Cr-Commit-Position: refs/heads/master@{#39052}
      7516fe1e