- 20 Jul, 2020 1 commit
-
-
Michael Achenbach authored
Some fuzzers replaced strigify and then caused uncaught errors from harness methods using prettyPrinted. Bug: chromium:1102897 Change-Id: I7ae6a90040ba0aa5ec1efa4a8b73e053ec75dd79 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2304814 Auto-Submit: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#68947}
-
- 24 Apr, 2020 2 commits
-
-
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: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67361}
-
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: Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#67349}
-
- 23 Apr, 2020 1 commit
-
-
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: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67327}
-
- 23 Mar, 2020 1 commit
-
-
Clemens Backes authored
The behaviour was clarified in the spec: https://github.com/WebAssembly/exception-handling/pull/97 br_on_exn (and also rethrow, which will be added in another CL) should trap on nullptr. This CL implements this by an explicit check on each br_on_exn (within {GetExceptionTag}). This check will be redundant if several br_on_exn follow each other. Since also the runtime call for {GetExceptionTag} is redundant, and also the fact that we do a runtime call is suboptimal, I consider the whole implementation prototypical for now anyway. R=jkummerow@chromium.org CC=aheejin@chromium.org Bug: v8:10128 Change-Id: I234c3183f93fe0884aadd2ab6dbd6c2b7a07c660 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113381 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66826}
-
- 23 Aug, 2019 1 commit
-
-
Sigurd Schneider authored
With this Cl, a function that has been marked for deoptimization will not be reported as optimized. This protects against potential races where an mjsunit tests assertUnoptimized, and the optimized code for the function has been marked for deoptimization, but not been disposed of yet. The potential for this race has been discovered in the context of bug v8:9563, but this CL is not a fix for that bug. Change-Id: I89d8aa85f19033e6b823324b3307b95d61367147 Bug: v8:9563 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763543Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63377}
-
- 03 Jul, 2019 1 commit
-
-
Michael Starzinger authored
This assertion was borked, as it accepted obviously "same" values like the same object. This fixes the predicate by switching both assertSame and assertNotSame to use {Object.is} underneath. It also adds a new respective regression test (gotta test the tester). R=ahaas@chromium.org TEST=message/mjsunit/fail/assert_not_same Change-Id: I6ba20c4b8b96a736ab924715b1cad78f2f43a120 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687541Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62512}
-
- 30 Apr, 2019 1 commit
-
-
Frederik Gossen authored
Ignore the error type in {assertThrows} only if it was not passed as an argument. If users do not care about the error type they can user the generic type {Error}. Before this change, an undefined error type would simply be ignored. A simple typo could therefore disable the error type assertion without being recognized. Change-Id: I9becfd0bf14dcaa511854e65ff94f94481cc79b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585855 Commit-Queue: Frederik Gossen <frgossen@google.com> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61105}
-
- 06 Mar, 2019 1 commit
-
-
Jakob Gruber authored
This piggy-backs off similar support for lite mode, which silently skips tests that require optimization in lite (and now jitless) modes. Bug: v8:7777,v8:8778, v8:8885 Change-Id: I666d92685ca71682224028743f02d0cce3723135 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503758 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#60057}
-
- 06 Feb, 2019 1 commit
-
-
Clemens Hammacher authored
We often use raw assertPromiseResult with {success == assertUnreachable} for that. Having a separate helper increases readability and allows us to generate consistent (and better) error messages. R=titzer@chromium.org Bug: chromium:926311 Change-Id: I507941eacaafe6c576098d7829a76b27384a4fb6 Reviewed-on: https://chromium-review.googlesource.com/c/1456039Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59417}
-
- 04 Feb, 2019 1 commit
-
-
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: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59328}
-
- 01 Feb, 2019 3 commits
-
-
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: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#59296}
-
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: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#59284}
-
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: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59277}
-
- 22 Oct, 2018 1 commit
-
-
Ross McIlroy authored
BUG=v8:8293 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ic0e12cbcea76f76fce543714dee972c784095143 Reviewed-on: https://chromium-review.googlesource.com/c/1290795 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#56852}
-
- 21 Sep, 2018 1 commit
-
-
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: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#56107}
-
- 01 Aug, 2018 1 commit
-
-
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: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#54833}
-
- 11 Jun, 2018 1 commit
-
-
Clemens Hammacher authored
For errors, it just printed "Failure: expected <Error()> found <Error()>" and completely omitted the specific error type and the message. The new output is: Failure: expected: Error(Error: my explicit error) found: Error(ReferenceError: ffi is not defined) R=mstarzinger@chromium.org Change-Id: Ie17a97e4413c4585b9560fd1c408018ee8c06701 Reviewed-on: https://chromium-review.googlesource.com/1092746Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53625}
-
- 06 Jun, 2018 1 commit
-
-
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: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#53556}
-
- 30 Apr, 2018 1 commit
-
-
Andreas Haas authored
assertPromiseResult caused tests to timeout when the result of the promise was unexpected, e.g. rejected instead of the expected fulfillment. This CL cleans up the implementation of assertPromiseResult, adds better stack traces, and adds tests for all the important cases I can think of. R=mathias@chromium.org CC=clemensh@chromium.org Bug: v8:7570 Change-Id: I6ecb94fd3e5151502edf73c3bcdeb518b80fc81c Reviewed-on: https://chromium-review.googlesource.com/1032786 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#52882}
-
- 22 Feb, 2018 1 commit
-
-
Michael Achenbach authored
This migrates harness adjustments, to be loaded after mjsunit.js on fuzzers for correctness fuzzing. This is the first step adding deeper pretty printing. Other adjustments will be added in follow ups. Bug: chromium:813833 Change-Id: I51168a31e733d54808cb8853a1c90e897acf3791 Reviewed-on: https://chromium-review.googlesource.com/930565 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#51481}
-
- 21 Feb, 2018 1 commit
-
-
Clemens Hammacher authored
Crankshaft is gone, and this function is not used anywhere. R=mstarzinger@chromium.org Bug: v8:7310,v8:6408 Change-Id: Ic1f859e659008c891cc35d20e95a8214de42bd21 Reviewed-on: https://chromium-review.googlesource.com/928981Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51445}
-
- 19 Feb, 2018 1 commit
-
-
Caitlin Potter authored
Previously, eval caching was only disabled if the root eval body code contained a tagged template. Per discussion on https://github.com/tc39/ecma262/pull/890, this is incorrect. This change tracks if eval caching is allowed during parsing, and uses this information to decide to insert new entries into the cache, or not. This change also removes the TemplateObject feedback kind, as it's no longer needed (behaves the same as Literal feedback). BUG=v8:3230, v8:2891 R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org Change-Id: Ib75abe9159baf4d8ad10f8de99d2152714bd0094 Reviewed-on: https://chromium-review.googlesource.com/916945 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51373}
-
- 31 Oct, 2017 1 commit
-
-
Jakob Kummerow authored
Implicit case-fallthrough strikes again. Bug: v8:6791 Change-Id: Iee6422a67797f8958527507bac538bcdac2ebddc Reviewed-on: https://chromium-review.googlesource.com/747075Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#49057}
-
- 27 Oct, 2017 1 commit
-
-
Georg Neis authored
R=jkummerow@chromium.org Bug: v8:6791 Change-Id: I9eb5b9aeeb060d660ec41b7a3287089edd833197 Reviewed-on: https://chromium-review.googlesource.com/737796Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#48992}
-
- 25 Oct, 2017 1 commit
-
-
Andreas Haas authored
This reverts commit 361bb1a0. Reason for revert: See https://crbug.com/v8/6981 BUG=v8:6981 Original change's description: > [test] Refactor assertPromiseResult > > This patch introduces assertPromiseFulfills and assertPromiseFulfills as > a replacement for assertPromiseResult because it’s more JavaScript-y. > > BUG=v8:6921 > R=ahaas@chromium.org > > Also-By: ahaas@chromium.org > Change-Id: I2f865dba3992ddf3b58987bf0b376d143edb5c31 > Reviewed-on: https://chromium-review.googlesource.com/718746 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48578} Change-Id: Ie760d2422451f16acc616aae001fe9fd18bf5cd4 Reviewed-on: https://chromium-review.googlesource.com/738249Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#48936}
-
- 16 Oct, 2017 1 commit
-
-
Mathias Bynens authored
This patch introduces assertPromiseFulfills and assertPromiseFulfills as a replacement for assertPromiseResult because it’s more JavaScript-y. BUG=v8:6921 R=ahaas@chromium.org Also-By: ahaas@chromium.org Change-Id: I2f865dba3992ddf3b58987bf0b376d143edb5c31 Reviewed-on: https://chromium-review.googlesource.com/718746 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#48578}
-
- 11 Oct, 2017 1 commit
-
-
Michal Majewski authored
Skipped the tests that are not suitable for deoptimization fuzzing. regress/regress-2618 test fixed to check kMaybeDeopted flag. Minor code style fix in mjsunit.js. Bug: v8:6900 Change-Id: Icc02a6b99005ae08ee7cb6cf2c1e9137329d79d3 Reviewed-on: https://chromium-review.googlesource.com/708797 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48444}
-
- 09 Oct, 2017 1 commit
-
-
Michal Majewski authored
Adds the counter to x64 only. Bug: v8:6900 Change-Id: Ia290102b38f029a0b71c40e4b00ecc5f07dfa59c Reviewed-on: https://chromium-review.googlesource.com/704678 Commit-Queue: Michał Majewski <majeski@google.com> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48378}
-
- 06 Oct, 2017 1 commit
-
-
Ben L. Titzer authored
R=clemensh@chromium.org Bug: v8:6756 Change-Id: I3b25b89f3ead5c856be5c7ba3c7c236e595ce8de Reviewed-on: https://chromium-review.googlesource.com/695524 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48333}
-
- 02 Aug, 2017 1 commit
-
-
Julien Brianceau authored
Bug: chromium:750830 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Icab7b5a1c469d5e77d04df8bfca8319784e92af4 Reviewed-on: https://chromium-review.googlesource.com/595655 Commit-Queue: Julien Brianceau <jbriance@cisco.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47072}
-
- 01 Aug, 2017 1 commit
-
-
Caitlin Potter authored
Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
-
- 31 Jul, 2017 4 commits
-
-
Michael Achenbach authored
This reverts commit 409f84c9. Reason for revert: Breaks nosnap debug: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14288 Original change's description: > [async-iteration] implement spec-change to `yield` in async generators > > Per https://github.com/tc39/proposal-async-iteration/pull/102/files: > > AsyncGeneratorResolve no longer unwraps a value component. Instead, the > value is unwrapped before the builtin call via Await, allowing Promise > rejections to affect the generator control flow. > > Thus, all `yield <expr>` implicitly become `yield await <expr>`. > > Additionally, `return <expr>` becomes `return await <expr>`. Finally, when > the generator is resumed with `.return()`, the parameter passed to .return() > is awaited before generator execution properly continues). > > BUG=v8:5855 > R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5 > Reviewed-on: https://chromium-review.googlesource.com/523844 > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47011} TBR=rmcilroy@chromium.org,adamk@chromium.org,yangguo@chromium.org,neis@chromium.org,littledan@chromium.org,gsathya@chromium.org,caitp@igalia.com Change-Id: Ie6ad7e5410a3a89aab7a5dc68de36eb27b9354fe No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5855 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/593952Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47013}
-
Caitlin Potter authored
Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5 Reviewed-on: https://chromium-review.googlesource.com/523844 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#47011}
-
Leszek Swirski authored
Remove opt_count from SFI, which only had two real uses: 1. Detecting OSR in tests -- replaced with a stack walk in %GetOptimizationStatus 2. Naming optimization log files -- replaced with the optimization id This allows us to remove a field from the SFI, moving the bailout reason into the counters field. As a drive-by, add optimization marker information (e.g. marked for optimization) to the optimization status. Change-Id: Id77deb5dd5439dfba058a7e1e1748de26b717d0d Reviewed-on: https://chromium-review.googlesource.com/592028Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47009}
-
Clemens Hammacher authored
The bug was introduced in a previous refactoring: https://chromium-review.googlesource.com/c/455555/14/test/mjsunit/mjsunit.js R=mstarzinger@chromium.org CC=gsathya@chromium.org Change-Id: I49d2797c3ba834c89011910a81cffd9e119e719f Reviewed-on: https://chromium-review.googlesource.com/593612Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47004}
-
- 26 Jul, 2017 1 commit
-
-
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: Adam Klein <adamk@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46910}
-
- 25 Jul, 2017 1 commit
-
-
Clemens Hammacher authored
Extend the errors.js mjsunit test to also check for the message in the generated errors. This will help catch bugs later, e.g. when refactoring the way we output errors: https://chromium-review.googlesource.com/c/565282 Drive-by 1: Fix a superfluous period in one error message. Drive-by 2: Fix a weird exception catching construct in the test. R=titzer@chromium.org Change-Id: I1c2e92fb2c34a481cbf8802153f8502452d45348 Reviewed-on: https://chromium-review.googlesource.com/582960Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46858}
-
- 18 Jul, 2017 1 commit
-
-
Camillo Bruni authored
Change-Id: I50ae9d96545f63bdb5ca27a23ea3a04c8764678a Reviewed-on: https://chromium-review.googlesource.com/574533Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#46734}
-
- 12 Jul, 2017 1 commit
-
-
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: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#46602}
-