1. 20 Sep, 2019 1 commit
  2. 11 Sep, 2019 1 commit
  3. 06 Sep, 2019 1 commit
  4. 29 Aug, 2019 2 commits
    • Seth Brenith's avatar
      [cleanup][torque] Use @generateCppClass in some simple cases, part 2 · a5811358
      Seth Brenith authored
      This patch is mostly mechanical. A few changes in
      implementation-visitor.cc might be worth mentioning:
      - Don't generate both field offset macros and class definitions for the
        same class. This was mostly just to keep me from forgetting to remove
        the DEFINE_FIELD_OFFSET_CONSTANTS part when converting classes, but
        also helpfully flagged that FixedArrayBase wasn't using the generated
        class that it requested.
      - Generate forward declarations for all tq-defined classes in
        internal-class-definitions-tq.h. This is helpful for making things
        compile when classes have fields of other class types.
      - When generating accessors for union types, use the nearest class type
        that contains the entire union rather than plain Object. This is
        important for compile-time type safety. It also required a few minor
        fixes elsewhere (isolate.cc, modules.cc, scope-info.cc,
        source-text-module.cc, and a correction of the field types in
        CallHandlerInfo to match how they're set in api.cc).
      
      Change-Id: I3b9280e30779ce57fb9f3629eecfec898e26d708
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774976Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63458}
      a5811358
    • Leszek Swirski's avatar
      [scopes] Push sloppy eval check through eval scopes · f6057ff1
      Leszek Swirski authored
      Sloppy eval extends the outer declaration scope's context. This is also
      true for sloppy eval inside of other sloppy evals -- the outer declaration
      scope's context is extended rather than the outer sloppy eval's
      declaration scope. However, we consider eval scopes to also be declaration
      scopes, for the purposes of strict eval and caching lookup variables. So,
      we need to make sure that we skip through sloppy eval scopes when marking
      a scope as calls_sloppy_eval.
      
      In fact, we implement this rather as never marking sloppy eval scopes as
      calls_sloppy_eval, under the assumption that the parent scope will already
      have been marked calls_sloppy_eval by the outer eval.
      
      As a drive-by, fix a TODO to move this logic from calls_sloppy_eval() to
      RecordEvalCall(), rename the variable to something more meaningful, and
      make Snapshotting to use a new calls_eval bit on Scope.
      
      Bug: chromium:996751
      Change-Id: I27ccc7ef429a7ce60b3bb02bf64a3820ae4a2c36
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773247
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63455}
      f6057ff1
  5. 12 Aug, 2019 1 commit
  6. 07 Aug, 2019 1 commit
  7. 30 Jul, 2019 1 commit
    • Joyee Cheung's avatar
      [class] parse private accessors · a6dd7f1c
      Joyee Cheung authored
      This patch adds:
      
      - VariableMode::kPrivateMethod
      - VariableMode::kPrivateSetterOnly
      - VariableMode::kPrivateGetterOnly
      - VariableMode::kPrivateGetterAndSetter
      
      And replace the previous RequiresBrandCheckFlag by inferring
      whether the brand check is required from these VariableModes.
      It is then possible to check duplicate non-complementary
      accessors in the parsers and throw early errors, and allow
      complementary accessors to be associated with the same
      private name variable.
      
      This patch also adds the following AssignType:
      
      - PRIVATE_METHOD
      - PRIVATE_GETTER_ONLY
      - PRIVATE_SETTER_ONLY
      - PRIVATE_GETTER_AND_SETTER
      
      corresponding to the new VariableModes so that it's possible
      to generate specialized code for different type of
      private accessor declarations.
      
      Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
      
      Bug: v8:8330
      Change-Id: I0fb61b1be248630d1eadd74fb16d7d64a421f4c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695204
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62988}
      a6dd7f1c
  8. 19 Jun, 2019 1 commit
  9. 18 Jun, 2019 1 commit
  10. 23 May, 2019 2 commits
  11. 16 May, 2019 1 commit
  12. 13 May, 2019 1 commit
  13. 10 May, 2019 1 commit
    • Ross McIlroy's avatar
      Revert "[class] implement private method declarations" · bf07d790
      Ross McIlroy authored
      This reverts commit b9191bd3.
      
      Reason for revert: Clusterfuzz bugs
      BUG=chromium:961507,chromium:961508
      
      Original change's description:
      > [class] implement private method declarations
      >
      > This patch implements the declarations of private methods, the access
      > of private methods would be left to a future patch.
      > When a private methods declaration is encountered, we now:
      >
      > - Create a brand symbol during class evaluation and store it in the
      >   context.
      > - Create the closures for the private methods
      > - Load the brand from the context and store it in the instance in the
      >   constructor.
      >
      > Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
      >
      > Bug: v8:8330
      > Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61387}
      
      TBR=rmcilroy@chromium.org,gsathya@chromium.org,verwaest@chromium.org,joyee@igalia.com
      
      Change-Id: I429bbe8af9f94598de132814aa2c3ab9fa69b986
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8330
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605730
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61406}
      bf07d790
  14. 09 May, 2019 1 commit
  15. 09 Apr, 2019 1 commit
  16. 12 Mar, 2019 1 commit
  17. 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
  18. 31 Jan, 2019 1 commit
  19. 30 Jan, 2019 1 commit
  20. 28 Jan, 2019 2 commits
  21. 26 Dec, 2018 1 commit
  22. 17 Dec, 2018 1 commit
  23. 12 Dec, 2018 1 commit
    • Mythri's avatar
      Don't use feedback vector to infer IC kind and language mode · a36f2593
      Mythri authored
      Currently, the runtime IC functions deduce the IC kind and the language
      mode from the feedback slot kind. To support feedback free execution
      (for V8 lite mode and lazy allocation of feedback vectors) we need to
      infer the IC kind even when feedback vectors are not present.
      
      To be able to infer the language mode without feedback vectors, this cl
      forces context allocation in cases where we raise the language mode in
      the middle of a function. The language mode is the stricter of the
      language mode on the SFI and the language mode of the current context.
      
      This cl updates the bytecode handlers to check for valid feedback vectors
      and to call into runtime if the feedback vector is not allocated. It also
      adds new runtime functions to be able to infer the IC kind when there is no
      feedback vector. Most of the builtins and handlers remain unchanged because
      they are only used when feedback vector is present.
      
      Bug: v8:8394
      Change-Id: I1f77740c0d68ddaa0de076597f5f6bcb2e966d70
      Reviewed-on: https://chromium-review.googlesource.com/c/1358516
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58191}
      a36f2593
  24. 27 Nov, 2018 1 commit
  25. 26 Nov, 2018 1 commit
    • Marja Hölttä's avatar
      [iwyu] Include heap-inl.h less. · 0453d418
      Marja Hölttä authored
      - Remove heap-inl.h includes from places where it looked unnecessary. (This is a
        non-scientific approach, because it's probably pulled in indirectly anyway.)
      
      - Annotate places which include heap-inl.h because they need heap/ internals.
      
      - ACCESSORS legitimately needs heap-inl.h because of Heap::FromWritableHeapObject.
      
      - Add includes to heap/heap-write-barrier(-inl).h
      
      - A bunch of IWYU fixes discovered when working on this CL (includes which were
        missing because heap-inl.h pulls them in indirectly).
      
      BUG=v8:7490,v8:8238,v8:8499
      
      Change-Id: I00f9a74d430f13d7c080dca77a92b03bcca7ef96
      Reviewed-on: https://chromium-review.googlesource.com/c/1349241Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57814}
      0453d418
  26. 25 Nov, 2018 1 commit
  27. 24 Nov, 2018 1 commit
  28. 15 Nov, 2018 1 commit
    • Toon Verwaest's avatar
      [parser] Remove ContextSlotCache · 9486f220
      Toon Verwaest authored
      Now that we always cache lookups through scope-info-backed scopes on the
      entry-point scope-info-backed scope, we don't need additional caching
      per scope-info. The one missing piece was negative lookups, but they
      automatically turn into DynamicGlobals which we also cache on the entry
      scope.
      
      The one possible difference is that we don't cache across compilation,
      but seems unlikely to be very beneficial. We'll keep an eye out for
      regressions though.
      
      
      Change-Id: I23186d2b085d2042fafa32fb3cca88f88c61074c
      Reviewed-on: https://chromium-review.googlesource.com/c/1337731
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57544}
      9486f220
  29. 17 Sep, 2018 1 commit
  30. 03 Jul, 2018 2 commits
  31. 26 Jun, 2018 1 commit
    • Leszek Swirski's avatar
      [GetIsolate] Remove GetHeap in object setters · 1744f10a
      Leszek Swirski authored
      Remove the GetHeap call in object setters, replacing it with a new
      Heap::FromHeapObject method which explicitly tests for the object
      not being in RO space. The hope is that this method is used sparingly.
      
      As a drive-by, memoize the heap access in the write barrier macros,
      to avoid having to calculate the heap location twice.
      
      Bug: v8:7786
      Change-Id: I26d1c41c673eddced17be316da6d51a16ac853e7
      Reviewed-on: https://chromium-review.googlesource.com/1114614
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54033}
      1744f10a
  32. 20 Jun, 2018 1 commit
  33. 19 Jun, 2018 3 commits
  34. 18 Jun, 2018 1 commit
    • Toon Verwaest's avatar
      Drop stack-locals from ScopeInfo · 467eb149
      Toon Verwaest authored
      For now we keep params since NewSloppyArguments uses it to figure out how to structure the arguments object. We should be able to only keep params in case we have a special case though. E.g., leaf functions with no duplicate parameters don't need special treatment. Or we simply encode the parameter index for each context slot. (I'm not sure duplicates need special treatment.)
      
      
      Change-Id: Icfbb844e5331aeb93c50bc07edd58246c8aeb1d7
      Reviewed-on: https://chromium-review.googlesource.com/1104420
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53802}
      467eb149