1. 23 Apr, 2020 6 commits
    • Leszek Swirski's avatar
      [offthread] Move stress-background-compile to compiler.cc · a441cbfb
      Leszek Swirski authored
      Make --stress-background-compile a V8 flag rather than a d8 flag, so
      that it also tests unittests/cctests.
      
      Now, with this flag, every top-level script compile (that fulfills a
      couple of restrictions) will be both main-thread and background-thread
      compiled, taking the result of the background compile. In the future,
      we'll probably want to verify that the two results are equivalent.
      
      One of the necessary changes to allow tests to pass was to introduce a
      concept of a "temporary" script (with a temporary script id), which
      doesn't get added to the script list. This is to avoid the main-thread
      compile part of the stress-test having a debugger-visible side-effect,
      e.g. in tests that enumerate scripts. We can't just create new ids for
      such scripts, as then script-id expectation files no longer match.
      
      Bug: chromium:1011762
      Change-Id: I500bbf2cabea762e69aca3dbae247daae71192cb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120541
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67332}
      a441cbfb
    • Andreas Haas's avatar
      [wasm][liftoff][arm] Implement 32-bit atomic binops · 2d0482a3
      Andreas Haas authored
      R=clemensb@chromium.org
      
      Bug: v8:10108
      Change-Id: Ibb7e7e14e86957c6bf302fcfd3e1099d4f00c414
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154646
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67331}
      2d0482a3
    • Gus Caplan's avatar
      Implement logical assignment · b151d8db
      Gus Caplan authored
      https://tc39.es/proposal-logical-assignment/
      
      Bug: v8:10372
      Change-Id: I538d54af6b4b24d450d1398c74f76dd57fdb0147
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158119Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67330}
      b151d8db
    • Leszek Swirski's avatar
      [compile] Add an UnoptimizedCompileState class · 6458a529
      Leszek Swirski authored
      Move the persistent compilation state and Isolate inputs (such as the
      allocator, shared AST constants, hash seed, logger, etc.) which survives
      across both parse and compile, out of ParseInfo and into a new
      UnoptimizedCompileState class. Also add UnoptimizedCompilePerThreadState
      for per-thread state such as stack limit and RCS.
      
      In particular, this new state survives the ParseInfo being destructed,
      which means it is available after off-thread finalization. This allows a
      followup to access the PendingCompilationErrorHandler after finalization
      and report errors on merge.
      
      Bug: v8:10314
      Change-Id: Ia186bc0f267c704efd771aa1895f50a4525a8364
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105636
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67329}
      6458a529
    • Zhao Jiazhong's avatar
      [mips64][wasm-simd] Implement I64x2 splat extract_lane replace_lane · b9c3921d
      Zhao Jiazhong authored
      Change-Id: I815979c232f0c781a76dd7954fbba9edabec7359
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152071Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
      Cr-Commit-Position: refs/heads/master@{#67328}
      b9c3921d
    • Timothy Gu's avatar
      [builtins] Clean up the use of class_name / ES5 [[Class]] · 29c1eab9
      Timothy Gu authored
      Before ES2015, the ES spec had a [[Class]] internal slot for all
      objects, which Object.prototype.toString() would use to figure the
      returned string. Post-ES2015, the [[Class]] slot was removed in spec for
      all objects, with the @@toStringTag well-known symbol the proper way to
      change Object.prototype.toString() output.
      
      At the time, spec-identical handling without the use of [[Class]] was
      implemented in V8 for all objects other than API objects, where issues
      with the Web IDL spec [1] prevented Blink, and hence V8, to totally
      migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
      @@toStringTag on API class prototypes to manage the
      Object.prototype.toString() output, so the legacy [[Class]] handling in
      V8 has not been necessary for the past couple of years.
      
      This CL removes the remaining legacy [[Class]] handling in
      Object.prototype.toString(), JSReceiver::class_name(), and
      GetConstructorName(). However, it does not remove the class_name field
      in FunctionTemplateInfo, as it is still used for the `name` property of
      created functions.
      
      This CL also cleans up other places in the codebase that still reference
      [[Class]].
      
      This change should have minimal impact on web-compatibility. For the
      change to be observable, a script must do one of the following:
      
      1. delete APIConstructor.prototype[Symbol.toStringTag];
      2. Object.setPrototypeOf(apiObject, somethingElse);
      
      Before this CL, these changes will not change the apiObject.toString()
      output. But after this CL, they will make apiObject.toString() show
      "[object Object]" (in the first case) or the @@toStringTag of the other
      prototype (in the latter case).
      
      However, both are deemed unlikely. @@toStringTag is not well-known
      feature of JavaScript, nor does it get tampered much on API
      constructors. In the second case, setting the prototype of an API object
      would effectly render the object useless, as all its methods (including
      property getters/setters) would no longer be accessible.
      
      Currently, @@toStringTag-based API object branding is not yet
      implemented by other browsers. This V8 bug in particular has been an
      impediment to standardizing toString behavior. Fixing this bug will
      unblock [3] and lead to a better Web IDL spec, and better toString()
      compatibility for all.
      
      [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
      [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
      [3]: https://github.com/heycam/webidl/pull/357
      
      Bug: chromium:793406
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
      Commit-Queue: Timothy Gu <timothygu@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67327}
      29c1eab9
  2. 22 Apr, 2020 29 commits
  3. 21 Apr, 2020 5 commits