Make sure to use the callback passed to cleanupSome
Bug: v8:8179
Change-Id: Ia5d90b56edf80e05bdaf0dc520b555c29042b64c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655306
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62122}
It was a good flag, but it's time to say goodbye. Let us take a moment
to remember the good times we've had during its short time on earth.
It shipped in Chrome 74.
BUG=v8:8523
R=adamk@chromium.org, mathias@chromium.org, gsathya@chromium.org
Change-Id: I37e58360614c0bb3582b8bbfac795d5ed3e5a149
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1641205
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Auto-Submit: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#62099}
deopt-unlinked.js: bytecode flushing destroys the information that
%GetDeoptCount relies on, so turn that off for this test.
cleanupsome-after-unregister.js: the function-local object {o} is
assumed to be alive throughout the function, so make sure its live
range (from the optimizing compiler's view) extends that far.
Drive-by cleanup: drop some unnecessary casting boilerplate from
Genesis::InitializeGlobal_harmony_intl_date_format_range().
Change-Id: I28617f842fe046dd0875a9a082cfc55a3a076bcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617674
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61621}
Added null check when printing the brand with --print-ast.
Bug: chromium:961507, chromium:961508
Original change's description:
> [class] implement private method declarations
>
> This patch implements the declarations of private methods, the access
> of private methods would be left to a future patch.
> When a private methods declaration is encountered, we now:
>
> - Create a brand symbol during class evaluation and store it in the
> context.
> - Create the closures for the private methods
> - Load the brand from the context and store it in the instance in the
> constructor.
>
> Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
>
> Bug: v8:8330
> Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61387}
Change-Id: I3bf465f70c27914c9ec19f3f59ae018b28c9a866
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605521
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61459}
This reverts commit b9191bd355.
Reason for revert: Clusterfuzz bugs
BUG=chromium:961507,chromium:961508
Original change's description:
> [class] implement private method declarations
>
> This patch implements the declarations of private methods, the access
> of private methods would be left to a future patch.
> When a private methods declaration is encountered, we now:
>
> - Create a brand symbol during class evaluation and store it in the
> context.
> - Create the closures for the private methods
> - Load the brand from the context and store it in the instance in the
> constructor.
>
> Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
>
> Bug: v8:8330
> Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61387}
TBR=rmcilroy@chromium.org,gsathya@chromium.org,verwaest@chromium.org,joyee@igalia.com
Change-Id: I429bbe8af9f94598de132814aa2c3ab9fa69b986
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8330
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605730
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61406}
This patch implements the declarations of private methods, the access
of private methods would be left to a future patch.
When a private methods declaration is encountered, we now:
- Create a brand symbol during class evaluation and store it in the
context.
- Create the closures for the private methods
- Load the brand from the context and store it in the instance in the
constructor.
Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
Bug: v8:8330
Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61387}
It shipped in Chrome 73.
Bug: v8:6890
Change-Id: Idd8c98cf05a0d6e8fa58c5b0a34d079631f68b1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1582879
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#61005}
MicrotaskQueue associated to Context may be null after DetachGlobal,
and triggering FinalizationGroup clean up on the detached context
causes a crash.
This CL fixes the crash by cancelling the clean up on such a context.
Bug: chromium:937784
Change-Id: I57883ae0caf6c6bb35e482e441b6e09e921d9def
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552500
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60931}
Previously when an unresolved private name is not found
in the current scope but found in an outer class scope,
we forget to push it to the outer class scope so the
name would never get bound.
This patch simplifies ClassScope::ResolvePrivateNamesPartially()
and removes the search in outer class scopes since they are incomplete
at this point. Instead just push any private name that can't be
resolved in the current scope to the outer class scope so that it
gets handled later when the outer class scope is complete.
Bug: chromium:952722
Change-Id: Ia0dda74cac57a0a1e25a9a09575f55633c6093b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1567709
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#60863}
These tests make sure the ticks are correct when resolving against a
Promise.
Without the optimization, the result is:
"start,tick 1,tick 2,tick 3,tick 4,done,tick 5"
With the optimization, the result is:
"start,tick 1,tick 2,done,tick 3,tick 4,tick 5"
Bug: v8:8267
Change-Id: I6c6499c7c256927531a99bab4ae1c5bd5069ef7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1534884
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60615}
This implements the behavior discussed and specified here:
https://github.com/tc39/ecma262/issues/1461https://github.com/tc39/ecma262/pull/1470
As part of making this change, I realized that we didn't actually
toggle the behavior between the optimized and unoptimized version
based on the --harmony-await-optimization flag at all and just the
unoptimized version by default.
This patch removes the unoptimized version and uses the optimized
version as the default.
The other builtins that use this flag are not touched as part of this
CL, they will be updated separately.
Bug: v8:8998
Change-Id: I315e1b39dda91d0127b5e567986485d713eaa78d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1525872
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60310}
Unicode v12 was released today:
https://unicode.org/versions/Unicode12.0.0/
This patch updates the following sequence property escapes per
Unicode 12:
- Emoji_Flag_Sequence (no changes)
- Emoji_Keycap_Sequence (no changes)
- Emoji_Tag_Sequence (no changes)
- Emoji_ZWJ_Sequence
Note that Emoji_Modifier_Sequence is still using Unicode 11 data. This
will be fixed automatically once a version of ICU with Unicode 12 support
rolls into V8, at which point I'll update the relevant tests.
Bug: v8:7467
Change-Id: Iba575a471382ba7b029da06c2868c368ff43c649
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503764
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60052}
One of the early (no-op) returns forgot to check whether the
number of existing digits equals the number of required digits.
Bug: chromium:936506
Change-Id: Ic9a5b927306de3cd6b26662785ac11d866e12026
Reviewed-on: https://chromium-review.googlesource.com/c/1493133
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59929}
Currently, PRIVATE_NAME / PrivateIdentifier is not valid in
ObjectLiterals or other places expecting the PropertyName production.
A SyntaxError here prevents an access violation later on when attempting
to dereference a null property key
BUG=v8:8808
R=gsathya@chromium.org, littledan@chromium.org
Change-Id: Idde9c669cb48c1595b83115351a8fe0caed40eef
Reviewed-on: https://chromium-review.googlesource.com/c/1461161
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#59515}
New API is here: https://github.com/tc39/proposal-weakrefs/issues/55
The WeakCell parts stay in the old API, resulting in temporary code duplication
in some parts. Those parts will go away once the WeakCell-related parts are
migrated to the new API (but the spec needs some work first).
BUG=v8:8179
Change-Id: I81ca824a14d830e3c5fa515d5ad7e5f78c10e19d
Reviewed-on: https://chromium-review.googlesource.com/c/1378171
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58264}
Also disables --stress-flush-bytecode on some mjsunit tests which fail
when bytecode flushing is stressed due to test invariants.
Bug=v8:8395
Change-Id: If627910214b3c266e7776340ba182829148e8289
Reviewed-on: https://chromium-review.googlesource.com/c/1372071
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58230}
As per (https://github.com/tc39/proposal-string-matchall/pull/41), String.p.matchAll's fallback was removed.
Additionally, removed a IsNullOrUndefined check that was already covered by MaybeCallFunctionAtSymbol.
Updates to Test262 has been submitted: https://github.com/tc39/test262/pull/1990
Bug: v8:6890
Change-Id: I246cbbcb4641ebded704c5f772809f182deaa30e
Reviewed-on: https://chromium-review.googlesource.com/c/1369091
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58172}
This makes the deoptimizer happy, and is more consistent with other
Torque JS functions.
BUG=chromium:912504, v8:8021
R=tebbi@chromium.org, danno@chromium.org, mvstanton@chromium.org, gsathya@chromium.org
Change-Id: I4c86db9549c367dfab7f76b49a0cf3c69d3ec50b
Reviewed-on: https://chromium-review.googlesource.com/c/1366397
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58161}
This replaces Runtime_RunMicrotasks with Runtime_PerformMicrotaskCheckpoint.
RunMicrotasks forcibly runs Microtasks even when the microtasks are suppressed,
and may causes nested Microtasks in a problematic way. E.g. that confuses
v8::MicrotasksScope::IsRunningMicrotasks() and GetEnteredOrMicrotaskContext().
OTOH, PerformMicrotaskCheckpoint() doesn't run cause the failure as it
respects the microtask suppressions.
As all existing tests don't call RunMicrotasks() in the suppressed situation
(like Promise.resolve().then(()=>{%RunMicrotasks();})), this change should
not affect to these tests.
Change-Id: Ib043a0cc8e482e022d375084d65ea98a6f54ef3d
Reviewed-on: https://chromium-review.googlesource.com/c/1360095
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58068}
Taking kSystemPointerSize into account when determining the maximum
allowed BigInt size accidentally made the limit platform-specific.
This patch chooses a platform-independent constant (1<<30) instead.
Bug: chromium:909614
Change-Id: I4717969bc56e6dd5f1eed70b7e60e621989d0719
Reviewed-on: https://chromium-review.googlesource.com/c/1355625
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57983}
This is a reland of a5336471f2
Original change's description:
> [builtins] Implement Object.fromEntries
>
> Adds the Object.fromEntries() method behind
> --harmony-object-from-entries.
>
> > Includes an initial implementation of the new experimental builtin
> Object.fromEntries implemented by Daniel Clifford, and
> has been modified by Caitlin Potter to support a fast case to skip
> the iterator protocol when it can be done unobservably in common cases.
>
> There are some incidental changes: A number of CSA macros have been
> updated to use TNodes, and some Context arguments have been
> re-arranged to be implicit in Torque. >
>
> There are also a number of mjsunit tests written mirroring and
> expanding on the test262 tests.
>
> BUG=v8:8021
>
> Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc
> Co-authored-by: Daniel Clifford <danno@chromium.org>
> Co-authored-by: Caitlin Potter <caitp@igalia.com>
> Reviewed-on: https://chromium-review.googlesource.com/c/1337585
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57667}
Bug: v8:8021
Change-Id: I706e2d87bfc2f688e833c1b7d40ca82f5d80f5a2
Reviewed-on: https://chromium-review.googlesource.com/c/1346630
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57798}
This reverts commit a5336471f2.
Reason for revert: Fails nosnap debug tests: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21838
Original change's description:
> [builtins] Implement Object.fromEntries
>
> Adds the Object.fromEntries() method behind
> --harmony-object-from-entries.
>
> > Includes an initial implementation of the new experimental builtin
> Object.fromEntries implemented by Daniel Clifford, and
> has been modified by Caitlin Potter to support a fast case to skip
> the iterator protocol when it can be done unobservably in common cases.
>
> There are some incidental changes: A number of CSA macros have been
> updated to use TNodes, and some Context arguments have been
> re-arranged to be implicit in Torque. >
>
> There are also a number of mjsunit tests written mirroring and
> expanding on the test262 tests.
>
> BUG=v8:8021
>
> Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc
> Co-authored-by: Daniel Clifford <danno@chromium.org>
> Co-authored-by: Caitlin Potter <caitp@igalia.com>
> Reviewed-on: https://chromium-review.googlesource.com/c/1337585
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57667}
TBR=danno@chromium.org,caitp@igalia.com,tebbi@chromium.org
Change-Id: Id0cd8b16131f151a42dffbaca7e59ab17c68ab23
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8021
Reviewed-on: https://chromium-review.googlesource.com/c/1346116
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57677}
Adds the Object.fromEntries() method behind
--harmony-object-from-entries.
Includes an initial implementation of the new experimental builtin
Object.fromEntries implemented by Daniel Clifford, and
has been modified by Caitlin Potter to support a fast case to skip
the iterator protocol when it can be done unobservably in common cases.
There are some incidental changes: A number of CSA macros have been
updated to use TNodes, and some Context arguments have been
re-arranged to be implicit in Torque.
There are also a number of mjsunit tests written mirroring and
expanding on the test262 tests.
BUG=v8:8021
Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc
Co-authored-by: Daniel Clifford <danno@chromium.org>
Co-authored-by: Caitlin Potter <caitp@igalia.com>
Reviewed-on: https://chromium-review.googlesource.com/c/1337585
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57667}
GC needs to be able to read a bigint's length while the main thread may
change the length and the sign (bigints are intentionally mutable as
long as they haven't escaped to user code). Since both values are stored
in the same bitfield, we need to make these accesses atomic.
Also change right-trimming to not insert a filler when the object is
in large object space (it makes no sense there).
Bug: v8:8440
Change-Id: I72a1b6f1eda54566d3cfad554dda1a98ddd61975
Reviewed-on: https://chromium-review.googlesource.com/c/1337737
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57576}
Behavior in Release mode was correct; Debug mode triggered a DCHECK
failure that indicated an inefficiency: when a requested truncation
would be a no-op, we should return the original BigInt, rather than
creating a copy. In the special case of -2^(n-1), i.e. the smallest
negative n-bit integer, getting truncated to n bits, with n being a
multiple of kDigitBits, this shortcut was not taken.
Bug: v8:8426
Change-Id: I8e4595d9ac0dbef81aae06688f9a9636bd2d9cd9
Reviewed-on: https://chromium-review.googlesource.com/c/1325029
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57369}
- Add the WeakRef class and its deref() function.
- Add WeakFactory.prototype.makeRef
- Implement the "keep during job" behavior for WeakRef constructor and deref().
- Here we keep the targets alive longer than until the end of the job
(microtask), contradicting the spec. However, this is probably the indended
behavior, see https://github.com/tc39/proposal-weakrefs/issues/39 .
BUG=v8:8179
Change-Id: I41990d41ac1799e34f675d8431b9a7aa7ed3d48d
Reviewed-on: https://chromium-review.googlesource.com/c/1306435
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57242}
These tests rely on dropping references to objects either explicitly ("o =
null;") or implicitly ("o goes out of scope") and then doing gc. It's essential
that we haven't already marked the WeakCell pointing to o and marked it alive
before dropping the reference.
BUG=v8:8179
Change-Id: Ie0b73f05c4baa937cf6f28325454ff9087a71a2c
Reviewed-on: https://chromium-review.googlesource.com/c/1306437
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57115}
- Store dirty JSWeakFactories in a heap root (not native context) -
during GC there's no native context necessarily.
- Schedule one microtask per JSWeakFactory.
- Enter the context of the cleanup function before calling it.
BUG=v8:8179
Change-Id: Icaa245a08a60dd7325af828858ebe55d842c5bf6
Reviewed-on: https://chromium-review.googlesource.com/c/1298899
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57081}
The assertion was intended to verify that the function is only called
at appropriate times (at a point when it was called both by by other builtins, and by desugarings added in the parser and during bytecode generation) --- However, it didn't account for the case where
the wrapper Promise is resolved with another JSPromise with a
non-callable "then" method. (Step 12 of
https://tc39.github.io/ecma262/#sec-promise-resolve-functions):
"If IsCallable(thenAction) is false, then
Return FulfillPromise(promise, resolution)."
It would be observable to verify this behaviour by loading the "then"
value and asserting that it's non-callable, so instead the CSA_ASSERT
is just removed and replaced with a comment explaining the appropriate
use of the function.
BUG=chromium:897436, v8:5855
R=bmeurer@chromium.org
Change-Id: Ib4b11abfe3339409b57ccfda9c3f75a34e0db532
Reviewed-on: https://chromium-review.googlesource.com/c/1296909
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56916}
