1. 19 Feb, 2019 1 commit
  2. 14 Feb, 2019 2 commits
  3. 13 Feb, 2019 2 commits
  4. 08 Feb, 2019 2 commits
  5. 06 Feb, 2019 1 commit
    • Toon Verwaest's avatar
      [parser] Handle 'this' with a special ThisExpression rather than VariableProxy · 3f2b5017
      Toon Verwaest authored
      "this" is a very common expression. By using a single ThisExpression object
      we can both avoid allocating many unnecessary VariableProxies and specialize
      the resolution of this since we know where it's declared up-front. This also
      avoids having to special-case "this" reference handling in the paths that would
      behave differently for "this" than for regular references; e.g., with-scopes.
      
      The tricky pieces are due to DebugEvaluate and this/super() used as default
      parameters of arrow functions. In the former case we replace the WITH_SCOPE
      with FUNCTION_SCOPE so that we make sure that "this" is intercepted, and still
      rely on regular dynamic variable lookup. Arrow functions are dealt with by
      marking "this" use in ArrowHeadParsingScopes. If the parenthesized expression
      ends up being an arrow function, we force context allocate on the outer scope
      (and mark "has_this_reference" on the FUNCTION_SCOPE so DebugEvaluate in the
      arrow function can expose "this").
      
      The CL also removes the now unused ThisFunction AST node.
      
      Change-Id: I0ca38ab92ff58c2f731e07db2fbe91df901681ef
      Reviewed-on: https://chromium-review.googlesource.com/c/1448313Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59393}
      3f2b5017
  6. 04 Feb, 2019 1 commit
  7. 02 Feb, 2019 1 commit
  8. 28 Jan, 2019 2 commits
  9. 25 Jan, 2019 2 commits
  10. 24 Jan, 2019 1 commit
    • Mythri's avatar
      Reland "Change SetProperty/SetSuperProperty to infer language mode when possible" · e2846ea6
      Mythri authored
      This is a reland of 0896599f with a fix for
      failing layout test.
      
      Original change's description:
      > Change SetProperty/SetSuperProperty to infer language mode when possible
      >
      > In most cases, the language mode can be inferred from the closure and
      > the context. Computing the language mode instead of passing it around
      > simplifies the ICs and will make it possible to go towards lazily
      > allocating feedback vectors. Currently ICs obtain the language mode from
      > the feedback vectors and with lazy feedback allocation we may not always
      > have feedback vectors. Since computing language mode is a bit expensive
      > we want to defer it as far as possible.
      >
      > In Array builtins and other builtins like Reflect.Set we need to force a
      > language mode when setting the properties. To support these cases the
      > SetProperty methods allow the language mode to be overridden when needed.
      >
      > This is a first cl in a series of cls, that will defer the language mode
      > computation further and remove language mode where it is not needed.
      >
      > BUG: v8:8580
      > Change-Id: I9c2396e3bcfe77c3c9d6760c46d86954d54744b9
      > Reviewed-on: https://chromium-review.googlesource.com/c/1409426
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Mythri Alle <mythria@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58893}
      
      TBR: ahaas@chromium.org
      Change-Id: Id5d81eae91b55638dbc72168f0e5203e684869fb
      Reviewed-on: https://chromium-review.googlesource.com/c/1421077
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59075}
      e2846ea6
  11. 22 Jan, 2019 4 commits
  12. 21 Jan, 2019 1 commit
    • Peter Marshall's avatar
      [logger] Start cleaning up Logger class · 7da7c0bd
      Peter Marshall authored
      - Use unique ptrs for owned objects
      - Remove friendship with CpuProfiler and replace with public API
      - Remove unused method LogFailure()
      - Remove StopProfiler() which was only used by LogFailure() (removed)
        and one test, which can use StopProfilerThread() instead
      - Remove 'paused' state which was only used by the above
      - Remove 'engage' state. There is no reason we need this as along as
        users keep track of Engage/Disengage calls
      
      Drive-by cleanup:
      - Remove import of log.h from profile-generator.h
      - Remove unnecessary includes of log.h
      
      Change-Id: Ifc4ca156bef038c40953f8361ffea17788e3a59b
      Reviewed-on: https://chromium-review.googlesource.com/c/1424338
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58957}
      7da7c0bd
  13. 16 Jan, 2019 2 commits
  14. 15 Jan, 2019 1 commit
  15. 14 Jan, 2019 1 commit
  16. 10 Jan, 2019 3 commits
    • Leszek Swirski's avatar
      [destructuring] Get non-coercible message contents in runtime · 5e2c23e2
      Leszek Swirski authored
      For desrtucturing assignments from null/undefined, we throw an error
      that references the destructuring object literal's property name, e.g.
      for
        var { x } = null;
      we report that we cannot destructure 'x' from null.
      
      Rather than calculating this property during bytecode generation (and
      including it in the bytecode as an argument to the type error
      constructor), we can calculate it at exception throwing time, by
      re-parsing the source in a similar way to the existing call site
      rendering.
      
      This slightly decreases bytecode size and slightly decreases the amount
      of work the bytecode compiler needs to do. In the future, it could also
      allow us to give more detailed error messages, as we now have access to
      the entire AST and are on the slow path anyway.
      
      Bug: v8:6499
      Change-Id: Icdbd4667db548b4e5e62ef97797a3771b5c1bf72
      Reviewed-on: https://chromium-review.googlesource.com/c/1396080Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58706}
      5e2c23e2
    • Leszek Swirski's avatar
      [ignition] Remove useless iterator 'done' setting · f9a858fc
      Leszek Swirski authored
      The 'done' setting dance in BuildFillArrayWithIterator turned out to
      not be useful, as the StoreInArrayLiteral call could not ever throw an
      exception. Since iterator exceptions count as done, we are guarnteed to
      be done as soon as we enter the loop.
      
      Change-Id: Ibe2ba1fcbe383bfcfedb185169890b6931cc7884
      Reviewed-on: https://chromium-review.googlesource.com/c/1402792
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58695}
      f9a858fc
    • Leszek Swirski's avatar
      [ignition] Fix iteration finalization exception suppression · 7fbbce5f
      Leszek Swirski authored
      The IteratorClose spec specifies that exceptions in
      %GetMethod(iterator.return) are not suppressed by exceptions in the
      given continuation (body of a loop, assignments in destructuring),
      while exceptions in the execution of iterator.return() are.
      
      This means that we have to split out the property access + a typeof
      check to be outside the try-catch, and keep the call inside of it.
      
      The non-split version is only for cases when there is no 'throws'
      continuation (as is the case for yield* calling IteratorClose), so
      the existing BuildIteratorClose can be renamed to reflect this.
      
      Change-Id: Id71aea4fddd6ffb986bd9aaa09d29615a8800f71
      Reviewed-on: https://chromium-review.googlesource.com/c/1402789Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58694}
      7fbbce5f
  17. 09 Jan, 2019 1 commit
    • Leszek Swirski's avatar
      [parser] Don't desugar destructuring declarations. · 5e725a2b
      Leszek Swirski authored
      Emit a single destructuring assignment for destructuring declarations,
      which can be desugared by the bytecode generator. This allows us to
      remove destructuring desugaring from the parser (specifically, the
      pattern rewriter) entirely.
      
      The pattern "rewriter" is now only responsible for walking the
      destructuring pattern to declare variables, mark them assigned, and
      potentially rewrite scopes for the edge case of parameters with a sloppy
      eval.
      
      Note that since the rewriter is no longer rewriting, we have to flip the
      VariableProxy copying logic for var re-lookup, so that we now pass the
      new VariableProxy to the variable declaration and leave the original
      unresolved (rather than passing the original through and rewriting to a
      new unresolved VariableProxy).
      
      This change does have some effect on breakpoint locations, due to some
      of the available information changing between the parser and bytecode
      generator, however the new locations appear to be more consistent
      between assignments and declarations.
      
      Change-Id: I3a58dd0a387d2bfb8e5e9e22dde0acc5f440cb82
      Reviewed-on: https://chromium-review.googlesource.com/c/1382462
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58670}
      5e725a2b
  18. 08 Jan, 2019 1 commit
    • Toon Verwaest's avatar
      [parser] Disambiguate variables through expression-scope · f9529f6b
      Toon Verwaest authored
      Previously we'd always push variable proxies into the unresolved list of the
      current scope, and possibly delete them from the list later in case they end up
      being declarations. If variables become assigned, there were two ways to mark
      them as such: The preparser would marked the variables tracked on the
      PreParserExpression, and the parser would traverse the LHS AST to find and mark
      all variables.
      
      After this CL, if the scope already knows it's tracking declarations, the
      variables are never added to the unresolved list in the first place. If the
      scope is ambigous, it tracks the variable proxies on the side and only adds
      them to the unresolved list if they end up being references rather than
      declarations. The same list is now used to bulk mark all LHS variables as
      assigned; uniformely for both the parser and the preparser.
      
      In a next step we'll also use the scope to create declarations. That way we can
      stop tracking variables_ on PreParserExpression altogether.
      
      Change-Id: I6ada37006cc2e066731f29cd4ea314550fc7959f
      Reviewed-on: https://chromium-review.googlesource.com/c/1397669
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58629}
      f9529f6b
  19. 07 Jan, 2019 3 commits
  20. 04 Jan, 2019 1 commit
  21. 03 Jan, 2019 1 commit
  22. 27 Dec, 2018 1 commit
  23. 26 Dec, 2018 1 commit
  24. 21 Dec, 2018 2 commits
  25. 20 Dec, 2018 1 commit
  26. 19 Dec, 2018 1 commit