AddToDictionaryTemplate in literal-objects.cc was missing several
cases when handling the overwriting between properties with statically
known and dynamically computed names. This led to wrong enumeration
orders in class prototypes created from class templates.
Bug: v8:11158
Change-Id: I7381b4680ec533bd307a6c32d75c8a66394869df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536464
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71266}
... to --turbo-dynamic-map-checks. With the upcoming use in NCI code,
this feature is no longer used exclusively by Turboprop.
Bug: v8:8888
Change-Id: I61e01db086fd2e8566d2e2a09574be74b6e5a7bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546693
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71263}
The tests assert that funcs are optimized / deoptimized a certain way.
Bug: v8:9237, v8:11138
Change-Id: Ia4879e722e442be52de0bf93919eb03fecb88147
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529136
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71087}
This reverts commit 0147db5a4a.
Reason for revert: Data races: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34056
Original change's description:
> [super] Optimize super property access in JSNativeContextSpecialization
>
> Generalize the existing property lookup machinery
> (JSNCS::ReduceNamedAccess) to handle the case where the
> lookup_start_object and the receiver are different objects.
>
> Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit#heading=h.xqthbgih7l2l
>
> Bug: v8:9237
> Change-Id: I28b6d87ce6537acd8cf972bbe7dc6d63d581aadc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487122
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70988}
TBR=marja@chromium.org,mvstanton@chromium.org,neis@chromium.org
Change-Id: Ib5ddb919ae569fe5ddf266d986f1c8bc0fe9621a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2520908
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70992}
With non-super loads (receiver == lookup_start_object), we don't hit
the code in AccessorAssembler::GenericPropertyLoad calling
CSA::TryGetOwnProperty if the receiver (the lookup_start_object) is a
SMI.
But with super property loads, if we set up lookup_start_object the
right way, we will hit this code.
The code was assuming receiver is a HeapObject, which is too
restrictive. The receiver is only used for the accessor call, so
it's ok to make the type more generic.
Bug: v8:9237, chromium:1139786
Change-Id: I3167ccfb54a49ac1c401040a6f02fc1f3b98d9d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484366
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70647}
The actual fix is in LoadIC::ComputeHandler (checking
lookup_start_object == holder instead of receiver == holder) + the
LookupIterator changes for preserving lookup_start_object.
The rest is renaming / refactoring.
Reland: not relying on the prototype validity cell after all
Previous version: https://chromium-review.googlesource.com/c/v8/v8/+/2414039
Bug: v8:9237, chromium:1127653
Change-Id: I1949442f8ddcecb776f0c5d2cf737cb75f80e313
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2428588
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70112}
This fixes a case in which we forgot to assign flags to TextNodes
created through
AddBmpCharacters
AddNonBmpSurrogatePairs
AddLoneLeadSurrogates
AddLoneTrailSurrogates
functions. If these initially had a flag (e.g. case-insensitive 'i')
set, that information was lost. This bug resulted in missing case
folding in no_i18n builds (perhaps other things as well that just
aren't covered by our test suite).
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Bug: v8:10131,v8:10120
Change-Id: Icef4f0dbd47971a538e07bab2f1067c383fd59c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423718
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70106}
The actual fix is in LoadIC::ComputeHandler (checking
lookup_start_object == holder instead of receiver == holder) + the
LookupIterator changes for preserving lookup_start_object.
The rest is renaming / refactoring.
Bug: v8:9237, chromium:1127653
Change-Id: Ieef46fb46ababa79623951c48639429c5b552d2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414039
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70045}
With this CL d8 exits with an error code if there is an unhandled
promise rejection, e.g. due tue a failed assertion in a promise. Up
until now these assertions were just ignored.
Bug: v8:10556
Change-Id: I25f20e4be45a2de130562deb15f6a144f0ac976f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238569
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68503}
This changes black/white list to block/allow list.
Bug: v8:10619
Change-Id: Id55d72f90891670ca57b62dfeb6b3251025927dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257228
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68464}
Promise.{all,allSettled,any,race} should check resolve is a function before
opening their iteratable.
PR: https://github.com/tc39/ecma262/pull/1912
PR for Promise.any: https://github.com/tc39/proposal-promise-any/pull/65
This CL includes the following cleanup changes:
- Made it more explicit that the constructor is a Constructor.
- Removed unnecessary nested try blocks (a try can have both a catch and a label).
- Moved commonly used definitions out of promise-race.tq where they don't belong.
- Made the parameter order of PerformPromiseAll match the spec.
Bug: v8:10578
Change-Id: I9deb5d5106db7350a0d0ad52f165ff2469e7074b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232544
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68260}
Since ES6, optional arguments are treated the same as undefined. This
was recently cleaned up in https://github.com/tc39/ecma262/pull/1411.
The current Torque implementation of %TypedArray%.from incorrectly
interpreted the old (and confusing) language of a parameter being "not
present" as testing using arguments.length instead of testing directly
for undefined.
Bug: v8:10458
Change-Id: I055f1fa3be570a31a4f7369ba5b51b7d6b022f0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2168674
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67454}
PerformPromiseAll doesn't set iteratorRecord.[[Done]] to true if
Promise.resolve is not callable. This makes Promise.all call
IteratorClose.
BUG=v8:10452
Change-Id: Icbe17416a733f68ef09f1c610d715f544c2a3b8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2164789
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67416}
This is a reland of 29c1eab92e
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}
This reverts commit 29c1eab92e.
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/+/2163956
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67349}
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}
For example, when --fuzzing is off, %OptimizeFunctionOnNextCall now
crashes when given a non-function argument.
The following behaviors remain unchanged for now:
- %DeoptimizeFunction continues to do nothing if the function is not
optimized.
- %DeoptimizeNow continues to do nothing if the top-most JS function
is not optimized.
- %OptimizeOSR continues to do nothing if the function already has
optimized code.
Bug: v8:10249
Change-Id: I35d2f3d50ce3f94c8ffccabe50fb4df2b70ce028
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137406
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67121}
This is a reland of c6c9d4bf1b
Original change's description:
> Update unicode-regexp-ignore-case-noi18n expectations
>
> There appear to be one or several bugs in noi18n mode such that
> expectations in this test are no longer met. This CL updates
> expectations to the current behavior and re-enables the test so we at
> least preserve coverage in the other cases.
>
> The behavior in question should be investigated in the future
> (low priority).
>
> Bug: v8:10120
> Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66524}
Bug: v8:10120
Change-Id: Ib2ee68e26c2aebe2eeab3ec9f7bc263fd79f3773
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083291
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66550}
This reverts commit c6c9d4bf1b.
Reason for revert: Fails on noi18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/30737
Original change's description:
> Update unicode-regexp-ignore-case-noi18n expectations
>
> There appear to be one or several bugs in noi18n mode such that
> expectations in this test are no longer met. This CL updates
> expectations to the current behavior and re-enables the test so we at
> least preserve coverage in the other cases.
>
> The behavior in question should be investigated in the future
> (low priority).
>
> Bug: v8:10120
> Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66524}
TBR=jkummerow@chromium.org,jgruber@chromium.org
Change-Id: I960b90fe3679ef4c04782ca9ac9b91454e636dbb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083024
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66525}
There appear to be one or several bugs in noi18n mode such that
expectations in this test are no longer met. This CL updates
expectations to the current behavior and re-enables the test so we at
least preserve coverage in the other cases.
The behavior in question should be investigated in the future
(low priority).
Bug: v8:10120
Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66524}
The actual allocatable size still depends on the allocator;
in particular Blink's ArrayBufferAllocator is currently limited
to 2GB.
WebAssembly memories are not affected by this change (i.e. still
capped at 2GB as well).
For 32-bit platforms, the limit remains at 2**30-1 (=max smi) elements.
Bug: v8:4153
Change-Id: If0d6047dd4061028688d85a3dc0a2684dcca8693
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007495
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65924}
This reverts commit 91e3243d60.
Reason for revert: This deopts to the wrong point.
Original change's description:
> Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]()
>
> Current GetIterator bytecode loads and calls @@iterator property on a
> given object. This change extends the bytecode functionality to check
> whether the value returned after calling @@iterator property is a valid
> JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the
> returned value is not a valid JSReceiver. This change absorbs the
> functionality of additional two bytecodes - JumpIfJSReceiver and
> CallRuntime, that are part of the iterator protocol in the GetIterator
> bytecode.
>
> Bug: v8:9489
> Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Cr-Commit-Position: refs/heads/master@{#63704}
TBR=rmcilroy@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9489
Change-Id: I9324b5b01ead29912ad793a1e7b4d009643d7901
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960288
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65541}
The spec was normatively changed to simplify var scopes for parameter
expressions. Previously there was a per-parameter var scope in sloppy
mode so direct evals could introduce vars that did not escape the
parameter position. That semantics is complex both for the programmer
and implementation and has resulted in bugs in the past. Furthermore, it
has never been fully interoperable (with Safari in particular). The spec
was instead changed to be simpler: to have a single var scope for
sloppy evals in parameters that encloses the parameter scope and body
scope.
This simplification lets us remove expression-scope-reparenter.
Drive-by removal of stale reference to PatternRewriter.
Bug: v8:7532
Change-Id: Iade5594abe0009f7f3f6a1adad18628b17e1e779
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962471
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65517}
We use the compilation entry point as a caching scope for deserializing
lookups, to avoid redundantly iterating over parent scopes when
accessing the same variable multiple times.
However, this caching scope messes with lookups that are looking for
lexical name conflicts, as opposed to just resolving variables. In
particular, it messes with name conflict lookups and sloppy block
function hoisting checks, when there are other scopes in the way, e.g.
function f() {
let x;
try {
throw 0;
}
catch (x) {
// This catch is the entry scope
// Naive use of caches will find the catch-bound x (which is
// a VAR), and declare 'no conflict'.
eval("var x;");
// Naive use of caches will find the catch-bound x (which is
// a VAR), and determine that this function can be hoisted.
eval("{ function x() {} }");
}
}
Previously, we worked around this by avoiding cache uses for these
lookups, but this had the issue of instead caching the same variable
multiple times, on different scopes. In particular, we saw:
function f() {
with ({}) {
// This with is the entry scope, any other scope would do
// though.
// The conflict check on `var f` caches the function name
// variable on the function scope, the subsequent 'real'
// lookup of `f` caches the function name variable on the
// entry i.e. with scope.
eval("var f; f;");
}
}
With this patch, we change the caching behaviour to cache on the first
non-eval declaration scope above the eval -- in the above examples, this
becomes the parent function "f". For compilations with no intermediate
non-decl scopes (no with or catch scopes between the function and eval)
this becomes equivalent to the existing entry-point-based caching.
This means that normal lookups do have to (sometimes) iterate more scopes,
and we do have to be careful when using the cache to not use it for
lookups in these intermediate scopes (a new IsOuterScope DCHECK guards
against this), but we can now safely ignore the cache scope when doing
the name-collision lookups, as they only iterate up to the outer
non-eval declaration scope anyway.
Bug: chromium:1026603
Bug: chromium:1029461
Change-Id: I9e7a96ce4b8adbc7ed47a49fba6fba58b526235b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955731
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65391}
This reverts commit 48c9ca4462.
Reason for revert: Possible clusterfuzz issues
Bug: chromium:1028952
Original change's description:
> [names] Fix some test262 name tests to conform with spec changes
>
> In order to reflect web reality, TC39 has made some slight changes to
> name descriptors, see https://github.com/tc39/ecma262/pull/1490 for
> details. V8 was mostly already in compliance with these changes, but
> ThrowTypeError and anonymous classes needed some slight changes.
>
> Bug: v8:9646
> Change-Id: I163238954938f0c005e3adbc61b90498e01436da
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1764622
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63373}
TBR=gsathya@chromium.org,joshualitt@chromium.org
Bug: v8:9646
Change-Id: I06dd5527d30052d9c9dfc45a2862be930274aba7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939948
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65216}
... that started failing on AIX where the allocation of a huge
ArrayBuffer succeeds.
Bug: v8:4153
Change-Id: I322c71e01edccb254a523f7f85817971b6c68242
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914561
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64960}
... even with ptr-compr.
Although full uintptr-sized TypedArrays are not supported yet
we may already start using uint32-sized typed arrays as we no
longer rely on TypedArray length to be a Smi.
Bug: v8:4153
Change-Id: If179541ad4f02c4ec7de9d1f3836138fe526d8a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1905847
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64897}
This reverts commit b8ac4eb4dc.
Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1020533
Original change's description:
> [runtime] Correctly handle global stores when global object has proxies
>
> When global object has proxies we should first call hasProperty and
> then call SetProperty if has property returns true. This cl fixes both
> StoreGlobal and StoreLookupGlobal to correctly handle these cases.
>
> Bug: chromium:1018871
> Change-Id: I140514e2119c6bab2125abcdc1b19d46526be5ff
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1889885
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64687}
TBR=mythria@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1018871
Change-Id: I5abbf9275cba17576e1b1e492abd36d6bc1ca1bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893194
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64714}
When global object has proxies we should first call hasProperty and
then call SetProperty if has property returns true. This cl fixes both
StoreGlobal and StoreLookupGlobal to correctly handle these cases.
Bug: chromium:1018871
Change-Id: I140514e2119c6bab2125abcdc1b19d46526be5ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1889885
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64687}
When global object has proxies we should first call hasProperty and
then call GetProperty according to spec. This cl fixes both
LoadGlobal and LoadLookupGlobal to correctly handle these cases.
Also fixes tests that didn't expect hasProperty to be called.
Change-Id: I3a45df7ae24be74dd46cf04cafbf8c2d7018b3af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876059
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64580}
Both LO_SPACE and NEW_LO_SPACE use the basic page management system of
LargeObjectSpace, but implement different AllocateRaw methods (with
the NEW_LO_SPACE version shadowing the LO_SPACE version).
To clean this up, and allow other future LargeObjectSpace implementations
(in particular, an off-thread variant), refactored the current
LargeObjectSpace into a base class, and make both LargeObjectSpace
(renamed to OldLargeObjectSpace) and NewLargeObjectSpace extend this
class.
Bug: chromium:1011762
Change-Id: I41b45b97f2611611dcfde677213131396df03a5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876824
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64560}
Split up the test so each test runs in a fresh Isolate with pristine
protector state.
Note that testArrayConcatES5 was not split out because it is a duplicate
of mjsunit/array-concat.js, and testConcatRevokedProxy has already been
split out as mjsunit/es6/array-concat-revocable-revoked-proxy-[12].js.
Bug: v8:9837
Change-Id: I8f744b0263c82f1dae61a55032124d9129f8e6f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864007
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64366}
This reimplements the "--time" option of run-tests.py to print the
20 slowest tests, on top of json_test_results infrastructure just
like the bots do it.
Additionally this CL speeds up a bunch of slow tests.
Bug: v8:9396
Change-Id: I40797d2c8c3bfdd310b72f15cd1a035844b7c6f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803635
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63786}
Current GetIterator bytecode loads and calls @@iterator property on a
given object. This change extends the bytecode functionality to check
whether the value returned after calling @@iterator property is a valid
JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the
returned value is not a valid JSReceiver. This change absorbs the
functionality of additional two bytecodes - JumpIfJSReceiver and
CallRuntime, that are part of the iterator protocol in the GetIterator
bytecode.
Bug: v8:9489
Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#63704}
