Change-Id: I8ce540dcd1dd5384f96d1c47c9784fdfb0933c1e
Reviewed-on: https://chromium-review.googlesource.com/c/1298029Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56954}

GN should understand action outputs, so the header generated by the
run_torque action do not need to be separately listed in another
source_set.

Change-Id: I309e8c012eb0a0597a247806d36658c1d6e5d97b
Reviewed-on: https://chromium-review.googlesource.com/c/1297680Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56953}

Bug: v8:7980
Change-Id: Ic4c72b02c196b296105a6ddf9c3af9fb699ef8c5
Reviewed-on: https://chromium-review.googlesource.com/c/1297327Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#56952}

R=ulan@chromium.org
BUG=v8:8238

Change-Id: Idf6b3d4035b392dd1b20ff3e4cbdb60cdaada054
Reviewed-on: https://chromium-review.googlesource.com/c/1297325Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56951}

Bug: v8:5495, v8:8361
Change-Id: I7a03c7a4897b15112b978d232754076ad8753c4e
Reviewed-on: https://chromium-review.googlesource.com/c/1297311Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56950}

R=machenbach@chromium.org

No-Try: true
No-Tree-Checks: true
Bug: chromium:892433
Change-Id: Id323739be44ea55d73c712059520d7f5e684c97e
Reviewed-on: https://chromium-review.googlesource.com/c/1280304Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56949}

This changes the ReceiverOrOddball feedback on JSStrictEqual to
ReceiverOrNullOrUndefined feedback, which can also safely be
consumed by JSEqual (we cannot generally accept any oddball here
since booleans trigger implicit conversions, unfortunately).
Thus we replace the previously introduced CheckReceiverOrOddball
with CheckReceiverOrNullOrUndefined, and drop CheckOddball, since
we will no longer collect Oddball feedback separately.

TurboFan will then turn a JSEqual[ReceiverOrNullOrUndefined] into
a sequence like this:

```
left = CheckReceiverOrNullOrUndefined(left);
right = CheckReceiverOrNullOrUndefined(right);
result = if ObjectIsUndetectable(left) then
           ObjectIsUndetectable(right)
         else
           ReferenceEqual(left, right);
```

This significantly improves the peak performance of abstract equality
with Receiver, Null or Undefined inputs. On the test case outlined in
http://crbug.com/v8/8356 we go from

  naive: 2946 ms.
  tenary: 2134 ms.

to

  naive: 2230 ms.
  tenary: 2250 ms.

which corresponds to a 25% improvement on the abstract equality case.
For regular code this will probably yield more performance, since we
get rid of the JSEqual operator, which might have arbitrary side
effects and thus blocks all kinds of TurboFan optimizations. The
JSStrictEqual case is slightly slower now, since it has to rule out
booleans as well (even though that's not strictly necessary, but
consistency is key here).

This way developers can safely use `a == b` instead of doing a dance
like `a == null ? b == null : a === b` (which is what dart2js does
right now) when both `a` and `b` are known to be Receiver, Null or
Undefined. The abstract equality is not only faster to parse than
the tenary, but also generates a shorter bytecode sequence. In the
test case referenced in http://crbug.com/v8/8356 the bytecode for
`naive` is

```
StackCheck
Ldar a1
TestEqual a0, [0]
JumpIfFalse [5]
LdaSmi [1]
Return
LdaSmi [2]
Return
```

which is 14 bytes, whereas the `tenary` function generates

```
StackCheck
Ldar a0
TestUndetectable
JumpIfFalse [7]
Ldar a1
TestUndetectable
Jump [7]
Ldar a1
TestEqualStrict a0, [0]
JumpIfToBooleanFalse [5]
LdaSmi [1]
Return
LdaSmi [2]
Return
```

which is 24 bytes. So the `naive` version is 40% smaller and requires
fewer bytecode dispatches.

Bug: chromium:898455, v8:8356
Change-Id: If3961b2518b4438700706b3bd6071d546305e233
Reviewed-on: https://chromium-review.googlesource.com/c/1297315Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56948}

Also use low experiment percentage on CQ, since the builder's output is unused.

NOTRY=true
TBR=sergiyb@chromium.org

Bug: chromium:830557
Change-Id: Id024ab16e2944ec5e94b0209672ed6b77ae322a8
Reviewed-on: https://chromium-review.googlesource.com/c/1296466Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56947}

This is a reland of ec969ea3

Temporarily removes high memory usage test.

Original change's description:
> [builtins] Fix Array.p.join length overflow and invalid string length handling
>
> - Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
>   - When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
>   - Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
>
> - Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
>
> Bug: chromium:897404
> Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
> Reviewed-on: https://chromium-review.googlesource.com/c/1293070
> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56907}

Bug: chromium:897404
Change-Id: I4995893f6f9724b26c231d05619ad65dbccc7223
Reviewed-on: https://chromium-review.googlesource.com/c/1297675Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#56946}

TBR=tebbi@chromium.org
NOTRY=true

Change-Id: I2c5a1fc18efbbef7fd407000fa560bb75e5dc145
Reviewed-on: https://chromium-review.googlesource.com/c/1297324
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56945}

Previously StringToList use the length of the original string, which is
not the right value: we expect the length of the new array to be the
number of characters (codepoints).

Bug: v8:7980
Change-Id: I2efca5715323c4399cb45c53871ae349207f3458
Reviewed-on: https://chromium-review.googlesource.com/c/1297320
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56944}

This additionally optimizes ExpressionListToExpression in the parser to
allocate Nary if possible.  This allows us to drop unnecessary intermediate
objects in the parser, and avoids all the work altogether in the preparser.

Change-Id: I4a7d0ec3a28624c94ed85959d291e54eb81ffce3
Reviewed-on: https://chromium-review.googlesource.com/c/1297952
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56943}

For implementing wasm GC we need to revisit all places where we hold
WasmCode*. This CL reduces these places.

R=mstarzinger@chromium.org

Bug: v8:8217
Change-Id: I869e3c1817a3b9a24ab6aa281c0688bdf890dd33
Reviewed-on: https://chromium-review.googlesource.com/c/1297951Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56942}

This is a reland of 1d837093

Original change's description:
> [heap] Clean-up MemoryChunk allocation area constants.
> 
> Change-Id: I8ba59546ab93c7af98bc5ece2f0160628844dd92
> Reviewed-on: https://chromium-review.googlesource.com/c/1280584
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56908}

Change-Id: I110b70ee5cb5609e54e24e17f183b8c6d6086b8a
Reviewed-on: https://chromium-review.googlesource.com/c/1297318Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56941}

Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I44e62d53bc7b341a685eeca5691a86e915fcce44
Bug: v8:8344
Reviewed-on: https://chromium-review.googlesource.com/c/1292064Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56940}

This CL introduces a ScopedPtrList that's a view over an underlying ZonePtrList
buffer. Whenever a ScopedPtrList is the top-of-stack list, you can add values
through it, which will add them to the end of the buffer. Once the list is
done, you can copy out the values to a real ZonePtrList. That way you do not
need to guess what the required size of the list is, and you get better cache
locality.

Change-Id: I2d229d73bb25bbb450ae5b6767ab100abad2b3a3
Reviewed-on: https://chromium-review.googlesource.com/c/1296458
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56939}

Because of ordering issues we didn't set the wire bytes on the
{NativeModule} during {OnFinishedStream}. We then failed during
instantiation when trying to read the import names from the wire bytes.

This CL fixes this locally without much code churn. I plan to clean up
the interaction between {AsyncCompileJob} and {AsyncStreamingProcessor}
in a follow-up CL.

R=ahaas@chromium.org

Bug: chromium:898310
Change-Id: I06337a04ba380f87b803f325323208298d363f41
Reviewed-on: https://chromium-review.googlesource.com/c/1296467Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56938}

Change-Id: Id5e25509cba272083caee62a1ae7420f77f3fa50
Reviewed-on: https://chromium-review.googlesource.com/c/1297949Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56937}

In order to not confuse this with wasm memory.

R=mstarzinger@chromium.org

Bug: v8:8238
Change-Id: Ife183162a902ab1d141f6af95a9fa487a52379a1
Reviewed-on: https://chromium-review.googlesource.com/c/1296483
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56936}

Spec: https://tc39.github.io/ecma262/#sec-array.of

Note that the `IsConstructor` abstract operation [1] is implemented
as a `typeswitch`.

[1] https://tc39.github.io/ecma262/#sec-isconstructor

Bug: v8:8321
Change-Id: I17af918c1d928faf8a630b35432876baa96da217
Reviewed-on: https://chromium-review.googlesource.com/c/1296464Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56935}

NOTRY=true
TBR=sergiyb@chromium.org

Bug: v8:8291
Change-Id: I47445d10bd19beeacc90321e9177f0959b3b2f13
Reviewed-on: https://chromium-review.googlesource.com/c/1297316
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56934}

Change-Id: I2dbcd318b5ca1c40d0e76cb0316b275bf1b75589
Reviewed-on: https://chromium-review.googlesource.com/c/1296465Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56933}

Change-Id: Ibfb53be508930046c90fb01bc05615eef3ec79c7
Reviewed-on: https://chromium-review.googlesource.com/c/1297314Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56932}

This was fixed when introducing the IR.

Bug: v8:8216
Change-Id: Iebb212a2c21499b1738832457b660038e3a48975
Reviewed-on: https://chromium-review.googlesource.com/c/1297313Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56931}

This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/1276468, without the
change "Also forces all non-trampoline RelocInfo ByteArrays for builtins
to be generated into RO_SPACE."

Creates a single RelocInfo to be used by all builtin trampolines and
stores it as a root. All trampolines then substitute this for their
trampoline at generation time with DCHECKs to make sure it is
identical.

On x64, this results in the OLD_SPACE part of the startup snapshot
decreasing in size from 165656 to 130808 (-34848) bytes and RO_SPACE
(in the read-only snapshot) increasing from 31248 to 31272 (+24) bytes.

Bug: v8:8295
Change-Id: I0dee7dfaccd9b8025d7707b0bb90194173f1ee89
Reviewed-on: https://chromium-review.googlesource.com/c/1296459
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56930}

Minor simplifications and an additional overflow check.

R=mstarzinger@chromium.org

Bug: v8:8238
Change-Id: I169464319a0e70562f3a443f429e462d30dd2fa3
Reviewed-on: https://chromium-review.googlesource.com/c/1296482Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56929}

In preparation of porting Array.of to Torque, restructure the code and
add Construct() and ArrayCreate() to match spec text.
As a drive-by change, add and improve a bunch of CSA types and remove
direct usage of JSConstruct.

Bug: v8:8321

Change-Id: I445093388214d5b17b6dbc8d24c76ee296163071
Reviewed-on: https://chromium-review.googlesource.com/c/1296487Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56928}

Bug: v8:5495, v8:8361
Change-Id: I8bf37c75113cff212d9899c39cffbca47c448924
Reviewed-on: https://chromium-review.googlesource.com/c/1297310
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56927}

This makes the prototype add function check compatible with
constant field tracking (which is still under a flag).

Change-Id: I768feb55e1568f3e2642f573c9a79755fe3e8d9c
Bug: v8:5495, v8:8361
Reviewed-on: https://chromium-review.googlesource.com/c/1296481Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56926}

This CL introduces proper Oddball and ReceiverOrOddball states for the
CompareOperationFeedback, and updates the StrictEqual IC to collect this
feedback as well. Previously it would not collect Oddball feedback, not
even in the sense of NumberOrOddball, since that's not usable for the
SpeculativeNumberEqual.

The new feedback is handled via newly introduced CheckReceiverOrOddball
and CheckOddball operators in TurboFan, introduced by JSTypedLowering.
Just like with the Receiver feedback, it's enough to check one side and
do a ReferenceEqual afterwards, since strict equal can only yield true
if both sides refer to the same instance.

This improves the benchmark mentioned in http://crbug.com/v8/8356 from

  naive: 2950 ms.
  tenary: 2456 ms.

to around

  naive: 2996 ms.
  tenary: 2192 ms.

which corresponds to a roughly 10% improvement in the case for the
tenary pattern, which is currently used by dart2js. In real world
scenarios this will probably help even more, since TurboFan is able
to optimize across the strict equality, i.e. there's no longer a stub
call forcibly spilling all registers that are live across the call.

This new feedback will be used as a basis for the JSEqual support for
ReceiverOrOddball, which will allow dart2js switching to the shorter
a==b form, at the same peak performance.

Bug: v8:8356
Change-Id: Iafbf5d64fcc9312f9e575b54c32c631ce9b572b2
Reviewed-on: https://chromium-review.googlesource.com/c/1297309Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56925}

as part of the ongoing quest to get rid of Object*/Object** entirely.
Turns out the Deserializer was actually using unaligned MaybeObject**
pointers, which is undefined behavior. This patch makes the unaligned
values obvious (as "UnalignedSlot") and safe.

Bug: v8:3770
Change-Id: I20f2cca10cc025fa4867e56d9d740a3653837749
Reviewed-on: https://chromium-review.googlesource.com/c/1295792
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56924}

Remove ICUService and decentralize GetAvailableLocales to each class.
Refactor part of the Intl::GetAvailableLocales into Intl::BuildLocaleSet
as helper function.

Bug: v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ic82d919cbf7ec840a7df3b0fa040561534c105a1
Reviewed-on: https://chromium-review.googlesource.com/c/1295934
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56923}

See
https://chromium.googlesource.com/deps/inspector_protocol/+/460186cff1f0eead0d418626e7e75f52105182b2

Bug: chromium:891377
Change-Id: I10332e68fb33f8bc06a489162171c52675373536
Reviewed-on: https://chromium-review.googlesource.com/c/1297591
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56922}

Bug: v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I9653b862f58f25e35b5443fb5d47d69c36792768
Reviewed-on: https://chromium-review.googlesource.com/c/1295929
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56921}

as part of the continuing quest to get rid of Object*/Object**.
This is a fairly mechanical replacement of Object**/MaybeObject** with
wrapper objects carrying the same data. No change in behavior is intended.
Overloaded operators are provided to minimize code churn.

Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I76cee82b8bf2dd80a1b66f09dd2bb2b65038eeb7
Reviewed-on: https://chromium-review.googlesource.com/c/1287889
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56920}

wrapValue can destroy injected script.

R=dgozman@chromium.org

Bug: chromium:898062
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I60c8d4a4b510b896a175346a3ba72ca8be43bca5
Reviewed-on: https://chromium-review.googlesource.com/c/1297290Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56919}

This patch adds two improvements to gm.py:
(1) Fix "mksnapshot failure" detection to match the error message
    that is generated when embedded builtins are enabled.
(2) Run "gn gen" whenever build.ninja is missing. This can happen
    when out/<config>/args.gn exists already when gm.py is run for
    the first time.

Bug: v8:6666, v8:8335
Change-Id: I71836b832754fa21b6443d57a6c3c49718a9a8d1
Reviewed-on: https://chromium-review.googlesource.com/c/1294174Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56918}

Bug: v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I5a482014fa482c62b014506df45846496d909a63
Reviewed-on: https://chromium-review.googlesource.com/c/1295933Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56917}

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}

This reverts commit ec969ea3.

Reason for revert: test fails consistently on arm bots.
I can't repro the failure locally, but it does consume ~512MB of memory (for a single string, I think?), so my guess is that the bots don't have enough contiguous address space.

Original change's description:
> [builtins] Fix Array.p.join length overflow and invalid string length handling
> 
> - Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
>   - When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
>   - Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
> 
> - Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
> 
> Bug: chromium:897404
> Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
> Reviewed-on: https://chromium-review.googlesource.com/c/1293070
> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56907}

TBR=danno@chromium.org,peter.wm.wong@gmail.com,jgruber@chromium.org,tebbi@chromium.org

Change-Id: I8ca80bd75833aacc94ccb25ceb82bbc8880991db
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:897404
Reviewed-on: https://chromium-review.googlesource.com/c/1297471Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56915}