1. 10 Apr, 2017 2 commits
  2. 05 Apr, 2017 1 commit
  3. 04 Apr, 2017 1 commit
  4. 31 Mar, 2017 2 commits
  5. 29 Mar, 2017 2 commits
    • Caitlin Potter's avatar
      [async-iteration] implement AsyncGenerator · bf463c4d
      Caitlin Potter authored
      - Introduce new struct AsyncGeneratorRequest, which holds
        information pertinent to resuming execution of an
        AsyncGenerator, such as the Promise associated with the async
        generator request. It is intended to be used as a singly
        linked list, and holds a pointer to the next item in te queue.
      
      - Introduce JSAsyncGeneratorObject (subclass of
        JSGeneratorObject), which includes several new internal fields
        (`queue` which contains a singly linked list of
        AsyncGeneratorRequest objects, and `await_input` which
        contains the sent value from an Await expression (This is
        necessary to prevent function.sent (used by yield*) from
        having the sent value observably overwritten during
        execution).
      
      - Modify SuspendGenerator to accept a set of Flags, which
        indicate whether the suspend is for a Yield or Await, and
        whether it takes place on an async generator or ES6
        generator.
      
      - Introduce interpreter intrinsics and TF intrinsic lowering for
        accessing the await input of an async generator
      
      - Modify the JSGeneratorStore operator to understand whether or
        not it's suspending for a normal yield, or an AsyncGenerator
        Await. This ensures appropriate registers are stored.
      
      - Add versions of ResumeGeneratorTrampoline which store the
        input value in a different field depending on wether it's an
        AsyncGenerator Await resume, or an ordinary resume. Also modifies
        whether debug code will assert that the generator object is a
        JSGeneratorObject or a JSAsyncGeneratorObject depending on the
        resume type.
      
      BUG=v8:5855
      R=bmeurer@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org,
      littledan@chromium.org, neis@chromium.org
      TBR=marja@chromium.org
      
      Change-Id: I9d58df1d344465fc937fe7eed322424204497187
      Reviewed-on: https://chromium-review.googlesource.com/446961
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44240}
      bf463c4d
    • Marja Hölttä's avatar
      [parser] Set SharedFunctionInfo::has_duplicate_parameters later. · a8241878
      Marja Hölttä authored
      There's no need to set it so early - it's only needed when the function has
      really been parsed. This way we don't need to produce and store it for skipped
      inner functions.
      
      BUG=v8:5516
      
      Change-Id: Ida2abd44b494030771b5663a8eb326edb0a53b72
      Reviewed-on: https://chromium-review.googlesource.com/461160Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44235}
      a8241878
  6. 28 Mar, 2017 2 commits
    • Daniel Vogelheim's avatar
      [parser] Introduce 'contextual keyword tokens'. · ae1e8759
      Daniel Vogelheim authored
      Introduce 'contextual keyword' tokens, which are parsed as identifiers but
      in some contexts are treated by the parser like proper keywords. These are
      usually keywords introduced by recent ECMAScript versions, which for reasons
      of backwards compatibility are still permissible as regular identifiers in
      most contexts.
      
      Current usage is to check for Token::IDENTIFIER and then do a string
      compare. With this change the initial scan will scan them as usual, but
      will then record the token as IDENTIFIER plus a secondary token with the
      'contextual' value.
      
      BUG=v8:6902
      
      Change-Id: I6ae390382998cf756a23720bd481cb9c0eb78a72
      Reviewed-on: https://chromium-review.googlesource.com/459479
      Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44189}
      ae1e8759
    • Marja Hölttä's avatar
      [parser] Fix crash when lazy arrow func params contain destructuring assignments. · bc39a514
      Marja Hölttä authored
      As far as I can see, we have had this bug as long as destructuring assignments
      have been there (i.e., this is not regression).
      
      The problem was that Parser::DoParseFunction parsed the arrow function parameters
      but didn't rewrite the destructuring assignments in them.
      
      BUG=chromium:704811
      
      Change-Id: I0b1424e7d5103eda6efd51b403fe81a4ee235e01
      Reviewed-on: https://chromium-review.googlesource.com/459618
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44177}
      bc39a514
  7. 24 Mar, 2017 2 commits
  8. 23 Mar, 2017 1 commit
  9. 22 Mar, 2017 2 commits
  10. 21 Mar, 2017 1 commit
  11. 17 Mar, 2017 2 commits
    • Marja Hölttä's avatar
      [parser] Skipping inner funcs: store and use the inner function data. · 1191e6f6
      Marja Hölttä authored
      The data needed to be modified a bit to actually allow skipping over functions
      based on it. In particular, we need to allow skipping over an unknown inner
      scope structure (in the previous stage, we just had tests comparing the data
      against some baseline truth, so it wasn't needed).
      
      also removing the current "skip functions based on preparse data" logic,
      since preparser data is not used any more. At a later stage, I'll consider
      plugging the preparser-scope-analysis-data into that pipeline (so I don't want
      to remove the full code yet).
      
      Integration to the various forms of compilation is still incomplete; this CL
      integrates just enough to get the minimal example to pass:
      
      (function foo() {
        function preparsed() {
          var var1 = 10;
          function skip_me() {
            print(var1);
          }
          return skip_me;
        }
        return preparsed;
      })()()();
      
      BUG=v8:5516
      
      Change-Id: I0d24b4c3b338f7e6b6c3bf7cf2c1ceb29608e2f2
      Reviewed-on: https://chromium-review.googlesource.com/446336
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarDaniel Vogelheim <vogelheim@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43908}
      1191e6f6
    • Wiktor Garbacz's avatar
      [parser] Parse tasks: make them pass all tests. · 54db0236
      Wiktor Garbacz authored
      Parse tasks are still WIP so there is really no benefit turning them on.
      
      Turn off irrelevant tests.
      Fix duplicate parameters inverted logic.
      Fix use_counts tracking.
      Fix language mode, super_property, evals.
      Fix modules and stack overflow.
      
      BUG=v8:6093
      
      Change-Id: I8567b36eef7b9de6799789e7520810bde9c86e5b
      Reviewed-on: https://chromium-review.googlesource.com/455916
      Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43903}
      54db0236
  12. 14 Mar, 2017 2 commits
  13. 13 Mar, 2017 1 commit
    • yangguo's avatar
      [debugger] fix switch block source positions. · 09de9969
      yangguo authored
      The switch statement itself is part of the switch block.
      However, the source position of the statement is outside of
      the block. This leads to confusion for the debugger, if the
      switch block pushes a block context: the current context is
      a block context, but the scope analysis based on the current
      source position tells the debugger that we should be outside
      the scope, so we should have the function context.
      
      R=marja@chromium.org
      BUG=v8:6085
      
      Review-Url: https://codereview.chromium.org/2744213003
      Cr-Commit-Position: refs/heads/master@{#43744}
      09de9969
  14. 10 Mar, 2017 1 commit
  15. 03 Mar, 2017 3 commits
  16. 28 Feb, 2017 5 commits
  17. 24 Feb, 2017 1 commit
  18. 22 Feb, 2017 1 commit
  19. 20 Feb, 2017 2 commits
  20. 16 Feb, 2017 3 commits
    • jwolfe's avatar
      Implement new Function.prototype.toString --harmony-function-tostring · d1d4b9ce
      jwolfe authored
      For functions declared in source code, the .toString() representation
      will be an excerpt of the source code.
      * For functions declared with the "function" keyword, the excerpt
        starts at the "function" or "async" keyword and ends at the final "}".
        The previous behavior would start the excerpt at the "(" of the
        parameter list, and prepend a canonical `"function " + name` or
        similar, which would discard comments and formatting surrounding the
        function's name. Anonymous functions declared as function expressions
        no longer get the name "anonymous" in their toString representation.
      * For methods, the excerpt starts at the "get", "set", "*" (for
        generator methods), or property name, whichever comes first.
        Previously, the toString representation for methods would use a
        canonical prefix before the "(" of the parameter list. Note that any
        "static" keyword is omitted.
      * For arrow functions and class declarations, the excerpt is unchanged.
      
      For functions created with the Function, GeneratorFunction, or
      AsyncFunction constructors:
      * The string separating the parameter text and body text is now
        "\n) {\n", where previously it was "\n/*``*/) {\n" or ") {\n".
      * At one point, newline normalization was required by the spec here,
        but that was removed from the spec, and so this CL does not do it.
      
      Included in this CL is a fix for CreateDynamicFunction parsing. ')'
      and '`' characters in the parameter string are no longer disallowed,
      and Function("a=function(", "}){") is no longer allowed.
      
      BUG=v8:4958, v8:4230
      
      Review-Url: https://codereview.chromium.org/2156303002
      Cr-Commit-Position: refs/heads/master@{#43262}
      d1d4b9ce
    • Marja Hölttä's avatar
      [parser] No need to collect literal counts. · d21621cf
      Marja Hölttä authored
      Patch adopted from mvstanton@ ( https://codereview.chromium.org/2657413002/ )
      
      BUG=
      
      Change-Id: I4296b3d5694116e250a6bb88296fbed0f0c444e6
      Reviewed-on: https://chromium-review.googlesource.com/443246Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarDaniel Vogelheim <vogelheim@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43238}
      d21621cf
    • neis's avatar
      [ast] Mark temporaries as maybe-assigned by default. · 503ad143
      neis authored
      This is in order to prevent accidental bugs in desugarings.
      
      R=adamk@chromium.org
      BUG=v8:5636
      
      Review-Url: https://codereview.chromium.org/2693313002
      Cr-Commit-Position: refs/heads/master@{#43237}
      503ad143
  21. 15 Feb, 2017 2 commits
    • caitp's avatar
      [async-iteration] add support for for-await-of loops in Async Functions · 76ab55e3
      caitp authored
      When --harmony-async-iteration is enabled, it is now possible to
      use the for-await-of loop, which uses the Async Iteration protocol
      rather than the ordinary ES6 Iteration protocol.
      
      the Async-from-Sync Iterator object is not implemented in this CL,
      and so for-await-of loops will abort execution if the iterated object
      does not have a Symbol.asyncIterator() method. Async-from-Sync
      Iterators are implemented seperately in https://codereview.chromium.org/2645313003/
      
      BUG=v8:5855, v8:4483
      R=neis@chromium.org, littledan@chromium.org, adamk@chromium.org
      
      Review-Url: https://codereview.chromium.org/2637403008
      Cr-Commit-Position: refs/heads/master@{#43224}
      76ab55e3
    • Marja Hölttä's avatar
      [parser] Minor refactoring: parameter handling · e7ebb930
      Marja Hölttä authored
      - Different places used is_simple to mean different things; renamed one.
      
      - No need to do Scope::SetHasNoSimpleParameters multiple times.
      
      - Normally we create VAR parameters with a name, or (for destructuring
        parameters), TEMPORARY parmeters with an empty name. *Except* for
        destructuring rest parameters; then we create VAR a parameter with an empty
        name. This CL makes the empty-named parameter TEMPORARY instead of VAR.
      
      - This makes it clear that Parser::DeclareFormalParameters declares exactly
        those params which Parser::BuildParamerterInitializationBlock doesn't declare.
      
      - This unification doesn't change any functionality, but it makes sense to do
        since I'll need to make PreParser emulate what Parser does; this way I don't
        need to emulate the weird behavior.
      
      BUG=v8:5501
      
      Change-Id: Ifa6c116bc5908f4e03a36e74f47558888d1582bd
      Reviewed-on: https://chromium-review.googlesource.com/443106Reviewed-by: 's avatarDaniel Vogelheim <vogelheim@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43220}
      e7ebb930
  22. 13 Feb, 2017 1 commit