1. 20 Jul, 2020 1 commit
  2. 24 Apr, 2020 2 commits
    • Timothy Gu's avatar
      Reland "[builtins] Clean up the use of class_name / ES5 [[Class]]" · 1aa51b49
      Timothy Gu authored
      This is a reland of 29c1eab9
      
      Original change's description:
      > [builtins] Clean up the use of class_name / ES5 [[Class]]
      >
      > 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: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67327}
      
      Bug: chromium:793406
      Change-Id: Ia5d97bd4e1c44cadc6f18a17ffc9d06b038cf8f1
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163881
      Auto-Submit: Timothy Gu <timothygu@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67361}
      1aa51b49
    • Bill Budge's avatar
      Revert "[builtins] Clean up the use of class_name / ES5 [[Class]]" · 213016d6
      Bill Budge authored
      This reverts commit 29c1eab9.
      
      Reason for revert: Causes Blink test failures:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4222
      
      Original change's description:
      > [builtins] Clean up the use of class_name / ES5 [[Class]]
      > 
      > 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: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67327}
      
      TBR=verwaest@chromium.org,timothygu@chromium.org
      
      Change-Id: I678d2ffc1064b1d1ddb62024cc23c6c41b216ef4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:793406
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163956Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67349}
      213016d6
  3. 23 Apr, 2020 1 commit
    • 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
  4. 23 Mar, 2020 1 commit
  5. 23 Aug, 2019 1 commit
  6. 03 Jul, 2019 1 commit
  7. 30 Apr, 2019 1 commit
  8. 06 Mar, 2019 1 commit
  9. 06 Feb, 2019 1 commit
  10. 04 Feb, 2019 1 commit
    • Clemens Hammacher's avatar
      Reland "[test] Check for illegal uses of mjsunit methods" · ac73e1d5
      Clemens Hammacher authored
      This is a reland of a9e93572
      
      Original change's description:
      > [test] Check for illegal uses of mjsunit methods
      > 
      > The assertThrows and assertDoesNotThrow methods expect either a
      > function to execute, or a string to eval. In several tests however we
      > accidentally passed the *result* of the statement to be tested instead
      > of the code.
      > This CL adds check to catch such error early, and removes wrong uses.
      > In most places, we do not need to use assertDoesNotThrow anyway,
      > because exceptions are handled as test failures.
      > 
      > Drive-by: Unify catch syntax in mjsunit.js and make sure to propagate
      > MjsUnitAssertionErrors correctly.
      > 
      > R=mathias@chromium.org
      > 
      > Bug: v8:8562
      > Change-Id: I88894a667cbe0570774f748a9a23e8a527887a49
      > Reviewed-on: https://chromium-review.googlesource.com/c/1439238
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59277}
      
      Bug: v8:8562
      Change-Id: I3b26935f7b35302d499266155273ea271bf8151d
      Reviewed-on: https://chromium-review.googlesource.com/c/1449792Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59328}
      ac73e1d5
  11. 01 Feb, 2019 3 commits
    • Clemens Hammacher's avatar
      [wasm] Revise compile error messages · 327fd140
      Clemens Hammacher authored
      This CL revises some of our error messages, and removes unneeded parts
      (like "AsyncCompilation: " or "(null): "). It also extends existing
      tests to check for the precise error message more thoroughly to detect
      changes or nondeterminism earlier.
      
      R=titzer@chromium.org, ahaas@chromium.org
      
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Bug: chromium:926311
      Change-Id: I1ccfb307d4a61291f4582330152a53fbadd0848f
      Reviewed-on: https://chromium-review.googlesource.com/c/1445897
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59296}
      327fd140
    • Michael Achenbach's avatar
      Revert "[test] Check for illegal uses of mjsunit methods" · 14c06a34
      Michael Achenbach authored
      This reverts commit a9e93572.
      
      Reason for revert:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/23956
      Happened already 2 builds earlier, but the output is corrupted due to
      an outage.
      
      Original change's description:
      > [test] Check for illegal uses of mjsunit methods
      > 
      > The assertThrows and assertDoesNotThrow methods expect either a
      > function to execute, or a string to eval. In several tests however we
      > accidentally passed the *result* of the statement to be tested instead
      > of the code.
      > This CL adds check to catch such error early, and removes wrong uses.
      > In most places, we do not need to use assertDoesNotThrow anyway,
      > because exceptions are handled as test failures.
      > 
      > Drive-by: Unify catch syntax in mjsunit.js and make sure to propagate
      > MjsUnitAssertionErrors correctly.
      > 
      > R=​mathias@chromium.org
      > 
      > Bug: v8:8562
      > Change-Id: I88894a667cbe0570774f748a9a23e8a527887a49
      > Reviewed-on: https://chromium-review.googlesource.com/c/1439238
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59277}
      
      TBR=ahaas@chromium.org,clemensh@chromium.org,mathias@chromium.org
      
      Change-Id: Iec06c95dd3223f27297e5c6e02835d26b5e753e7
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8562
      Reviewed-on: https://chromium-review.googlesource.com/c/1449634Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59284}
      14c06a34
    • Clemens Hammacher's avatar
      [test] Check for illegal uses of mjsunit methods · a9e93572
      Clemens Hammacher authored
      The assertThrows and assertDoesNotThrow methods expect either a
      function to execute, or a string to eval. In several tests however we
      accidentally passed the *result* of the statement to be tested instead
      of the code.
      This CL adds check to catch such error early, and removes wrong uses.
      In most places, we do not need to use assertDoesNotThrow anyway,
      because exceptions are handled as test failures.
      
      Drive-by: Unify catch syntax in mjsunit.js and make sure to propagate
      MjsUnitAssertionErrors correctly.
      
      R=mathias@chromium.org
      
      Bug: v8:8562
      Change-Id: I88894a667cbe0570774f748a9a23e8a527887a49
      Reviewed-on: https://chromium-review.googlesource.com/c/1439238Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59277}
      a9e93572
  12. 22 Oct, 2018 1 commit
  13. 21 Sep, 2018 1 commit
    • Sam Clegg's avatar
      Export `mjsunit.formatFailureText` which is needed by `test-async.js` · 29685537
      Sam Clegg authored
      Without this the call to `formatFailureText` in `test-async.js`
      fails but goes unnoticed since the promise change is rejects
      which is not handled.  And d8 silently ignores the the unhandled
      rejections.
      
      Once `formatFailureText` was added it reveals a but where several
      tests were expecting `.equal` to be a deepEquals.  Specifically:
      
      test/mjsunit/es6/promise-all.js
      test/mjsunit/harmony/async-generators-resume-return.js
      test/mjsunit/harmony/async-generators-return.js
      test/mjsunit/harmony/async-generators-yield.js
      
      Making equals call `deepEquals` fixed that issue.
      
      Change-Id: I350c7d916147eaa7cf873bdaf273aebbaaa833c5
      Reviewed-on: https://chromium-review.googlesource.com/1236852
      Commit-Queue: Sam Clegg <sbc@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56107}
      29685537
  14. 01 Aug, 2018 1 commit
    • Andreas Haas's avatar
      [mjsunit] Move the implementation of testAsync into a separate file · 8c3c1b6c
      Andreas Haas authored
      The original implementation of 'testAsync' in mjsunit.js required to
      put the call to '%AbortJS' into an 'eval' statement. The reason is that
      this call requires the flag --allow-natives-syntax to be set, but the
      flag is not set in all mjsunit tests. With the use of 'eval'
      compilation errors can be avoided.
      
      The problem with this approach was that the fuzzer started to produce
      test cases which include the line 'eval("%AbortJS(message)");', and
      this line crashes intentionally. Different to the line
      '%Abort(message)', however, the 'eval' statement cannot be filtered
      so easily in the fuzzer. Therefore I pulled the implementation of
      'testAsync' into a separate file to avoid the 'eval'.
      
      Additional changes: I use '===' now instead of 'deepEquals' in
      AsyncAssertion.equals because 'deepEquals' is not available outside
      mjsunit.js. Using '===' seems more appropriate anyways because for
      all tests but one it is sufficient, and it is more precise than
      deepEquals.
      
      R=gsathya@chromium.org
      
      Bug: chromium:774841
      Change-Id: I47270aa63ff5a1d6aa76a771f9276eaaf579c5ac
      Reviewed-on: https://chromium-review.googlesource.com/1156598Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54833}
      8c3c1b6c
  15. 11 Jun, 2018 1 commit
  16. 06 Jun, 2018 1 commit
    • Andreas Haas's avatar
      [test] Make assertThrowsEquals use assertSame · 86a27207
      Andreas Haas authored
      The typical use of assertThrowsEquals is to check that a specific
      object is thrown. However, assertEquals only does a proper equality
      check for primitive types, not for complex types. Using assertSame
      does a reference equality check on objects, which is more what you
      would expect from assertThrowsEquals. For exception kind testing,
      assertThrowsEquals actually did not work correctly, assertThrows is
      better for that case.
      
      R=clemensh@chromium.org, mythria@chromium.org
      
      Change-Id: I24fb22e75fa33ebe90eb4bae40825119a054bba5
      Reviewed-on: https://chromium-review.googlesource.com/1087952Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53556}
      86a27207
  17. 30 Apr, 2018 1 commit
  18. 22 Feb, 2018 1 commit
  19. 21 Feb, 2018 1 commit
  20. 19 Feb, 2018 1 commit
  21. 31 Oct, 2017 1 commit
  22. 27 Oct, 2017 1 commit
  23. 25 Oct, 2017 1 commit
  24. 16 Oct, 2017 1 commit
  25. 11 Oct, 2017 1 commit
  26. 09 Oct, 2017 1 commit
  27. 06 Oct, 2017 1 commit
  28. 02 Aug, 2017 1 commit
  29. 01 Aug, 2017 1 commit
  30. 31 Jul, 2017 4 commits
  31. 26 Jul, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [tests] Async test framework · 61ed6a00
      Sathya Gunasekaran authored
      - No need for multiple assertAsyncRan() calls, just do t.plan(count)
      
      - Previously, if you forget to call assertAsyncRan(), the test will still
        pass, which is no longer true.
      
      - No longer hold global state (with
        asyncAssertsExpected). Previously if one assert wasn't hit then
        there's no way to find out which test failed. You'd have to
        comment each test and try again.
      
      - Each test runs independently in the microtask queue.
      
      - Better failure reporting by printing the entire function.
      
      Example error :
      === mjsunit/harmony/promise-prototype-finally ===
      abort: Expected asserts: 2, Actual asserts: 1
      in test: reject/finally/then
      assert => {
        assert.plan(2);
        Promise.reject(3).finally().then(
          assert.unreachable,
          x => {
            assert.equals(3, x);
          });
      }
      
      
      Change-Id: Ic3f6272e1e87b8b0121b8c8c7cce19cf90d1f1be
      Reviewed-on: https://chromium-review.googlesource.com/455555
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarDaniel Ehrenberg <littledan@chromium.org>
      Reviewed-by: 's avatarCaitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#46910}
      61ed6a00
  32. 25 Jul, 2017 1 commit
  33. 18 Jul, 2017 1 commit
  34. 12 Jul, 2017 1 commit
    • Camillo Bruni's avatar
      Reland "[mjsunit] Improve mjsunit stracktrace readability" · 34874b3b
      Camillo Bruni authored
      This is a reland of f720d024
      Original change's description:
      > [mjsunit] Improve mjsunit stracktrace readability
      > 
      > Format the function name and file-position into proper columns to easily spot
      > where the test code ends and the mjsunit framework code starts.
      > 
      > BEFORE:
      > Stack: Error
      >     at new MjsUnitAssertionError (test/mjsunit/mjsunit.js:36:18)
      >     at failWithMessage (test/mjsunit/mjsunit.js:310:11)
      >     at fail (test/mjsunit/mjsunit.js:327:12)
      >     at assertEquals (test/mjsunit/mjsunit.js:398:7)
      >     at closure (test/mjsunit/regress/regress-4121.js:20:7)
      >     at literals_sharing_test (test/mjsunit/regress/regress-4121.js:27:3)
      >     at test (test/mjsunit/regress/regress-4121.js:37:5)
      >     at eval (eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6), <anonymous>:1:1)
      >     at test/mjsunit/regress/regress-4121.js:49:6
      >     at Array.forEach.call (test/mjsunit/regress/regress-4121.js:50:7)
      >     throw new MjsUnitAssertionError(message);
      > 
      > AFTER:
      > Stack: MjsUnitAssertionError
      >     at assertEquals          test/mjsunit/mjsunit.js 398:7
      >     at closure               test/mjsunit/regress/regress-4121.js 20:7
      >     at literals_sharing_test test/mjsunit/regress/regress-4121.js 27:3
      >     at test                  test/mjsunit/regress/regress-4121.js 37:5
      >     at eval                  eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6)
      >     at                       test/mjsunit/regress/regress-4121.js 49:6
      >     at Array.forEach.call    test/mjsunit/regress/regress-4121.js 50:7
      >     throw new MjsUnitAssertionError(message);
      > 
      > 
      > Change-Id: Iad3460a648e26effb43c00426ab043743ee6a138
      > Reviewed-on: https://chromium-review.googlesource.com/563627
      > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46589}
      
      Change-Id: I44bf07f7be4114369315605542cafd17345b4397
      Reviewed-on: https://chromium-review.googlesource.com/567063Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46602}
      34874b3b