277420cd58c9e0e3d7f352c2ff8bc097b51fe3fe
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-07-12  Keith Miller  <keith_miller@apple.com>
2
3         getIndexQuickly should be const
4         https://bugs.webkit.org/show_bug.cgi?id=199747
5
6         Reviewed by Yusuke Suzuki.
7
8         * runtime/Butterfly.h:
9         (JSC::Butterfly::indexingPayload const):
10         (JSC::Butterfly::arrayStorage const):
11         (JSC::Butterfly::contiguousInt32 const):
12         (JSC::Butterfly::contiguousDouble const):
13         (JSC::Butterfly::contiguous const):
14         * runtime/JSObject.h:
15         (JSC::JSObject::canGetIndexQuickly const):
16         (JSC::JSObject::getIndexQuickly const):
17         (JSC::JSObject::tryGetIndexQuickly const):
18         (JSC::JSObject::canGetIndexQuickly): Deleted.
19         (JSC::JSObject::getIndexQuickly): Deleted.
20
21 2019-07-11  Justin Michaud  <justin_michaud@apple.com>
22
23         Add b3 macro lowering for CheckMul on arm64
24         https://bugs.webkit.org/show_bug.cgi?id=199251
25
26         Reviewed by Robin Morisset.
27
28         - Lower CheckMul for 32-bit arguments on arm64 into a mul and then an overflow check.
29         - Add a new opcode to air on arm64 for smull (multiplySignExtend32).
30         - Fuse sign extend 32 + mul into smull (taking two 32-bit arguments and producing 64 bits). 
31         - 1.25x speedup on power of two microbenchmark, 1.15x speedup on normal constant microbenchmark, 
32           and no change on the no-constant benchmark.
33         Also, skip some of the b3 tests that were failing before this patch so that the new tests can run
34         to completion.
35
36         * assembler/MacroAssemblerARM64.h:
37         (JSC::MacroAssemblerARM64::multiplySignExtend32):
38         * assembler/testmasm.cpp:
39         (JSC::testMul32SignExtend):
40         (JSC::run):
41         * b3/B3LowerMacros.cpp:
42         * b3/B3LowerToAir.cpp:
43         * b3/air/AirOpcode.opcodes:
44         * b3/testb3.cpp:
45         (JSC::B3::testMulArgs32SignExtend):
46         (JSC::B3::testMulImm32SignExtend):
47         (JSC::B3::testMemoryFence):
48         (JSC::B3::testStoreFence):
49         (JSC::B3::testLoadFence):
50         (JSC::B3::testPinRegisters):
51         (JSC::B3::run):
52
53 2019-07-11  Yusuke Suzuki  <ysuzuki@apple.com>
54
55         Unreviewed, revert r243617.
56         https://bugs.webkit.org/show_bug.cgi?id=196341
57
58         Mark pointed out that JSVirtualMachine can be gone in the other thread while we are executing GC constraint-solving.
59         This patch does not account that JavaScriptCore.framework is multi-thread safe: JSVirtualMachine wrapper can be destroyed,
60         and [JSVirtualMachine dealloc] can be executed in any threads while the VM is retained and used in the other thread (e.g.
61         destroyed from AutoReleasePool in some thread).
62
63         * API/JSContext.mm:
64         (-[JSContext initWithVirtualMachine:]):
65         (-[JSContext dealloc]):
66         (-[JSContext initWithGlobalContextRef:]):
67         (-[JSContext wrapperMap]):
68         (+[JSContext contextWithJSGlobalContextRef:]):
69         * API/JSVirtualMachine.mm:
70         (initWrapperCache):
71         (wrapperCache):
72         (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]):
73         (+[JSVMWrapperCache wrapperForJSContextGroupRef:]):
74         (-[JSVirtualMachine initWithContextGroupRef:]):
75         (-[JSVirtualMachine dealloc]):
76         (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
77         (-[JSVirtualMachine contextForGlobalContextRef:]):
78         (-[JSVirtualMachine addContext:forGlobalContextRef:]):
79         (scanExternalObjectGraph):
80         (scanExternalRememberedSet):
81         * API/JSVirtualMachineInternal.h:
82         * runtime/JSGlobalObject.h:
83         (JSC::JSGlobalObject::setWrapperMap):
84         (JSC::JSGlobalObject::setAPIWrapper): Deleted.
85         (JSC::JSGlobalObject::apiWrapper const): Deleted.
86         * runtime/VM.h:
87
88 2019-07-10  Tadeu Zagallo  <tzagallo@apple.com>
89
90         Optimize join of large empty arrays
91         https://bugs.webkit.org/show_bug.cgi?id=199636
92
93         Reviewed by Mark Lam.
94
95         Replicate the behavior of `str.repeat(count)` when performing `new Array(count + 1).join(str)`.
96         I added two new microbenchmarks:
97         - large-empty-array-join, which does not use the result of the join and runs ~44x faster and uses ~18x less memory.
98         - large-empty-array-join-resolve-rope, which uses the result of the join and runs 2x faster.
99
100                                                     baseline                    diff
101         large-empty-array-join                2713.9698+-72.7621    ^     61.2335+-10.4836       ^ definitely 44.3217x faster
102         large-empty-array-join-resolve-string   26.5517+-0.3995     ^     12.9309+-0.5516        ^ definitely 2.0533x faster
103
104         large-empty-array-join memory usage with baseline (dirty):
105             733012 kB current_mem
106             756824 kB lifetime_peak
107
108         large-empty-array-join memory usage with diff (dirty):
109             41904 kB current_mem
110             41972 kB lifetime_peak
111
112         Additionally, I ran JetStream2, sunspider and v8-spider and all were neutral.
113
114         * runtime/ArrayPrototype.cpp:
115         (JSC::fastJoin):
116
117 2019-07-08  Keith Miller  <keith_miller@apple.com>
118
119         Enable Intl.PluralRules and Intl.NumberFormatToParts by default
120         https://bugs.webkit.org/show_bug.cgi?id=199288
121
122         Reviewed by Yusuke Suzuki.
123
124         These features have been around for a while. We should turn them on by default.
125
126         * runtime/IntlNumberFormatPrototype.cpp:
127         (JSC::IntlNumberFormatPrototype::finishCreation):
128         * runtime/IntlObject.cpp:
129         (JSC::IntlObject::finishCreation): Deleted.
130         * runtime/IntlObject.h:
131         * runtime/Options.h:
132
133 2019-07-08  Antoine Quint  <graouts@apple.com>
134
135         [Pointer Events] Enable only on the most recent version of the supported iOS family
136         https://bugs.webkit.org/show_bug.cgi?id=199562
137         <rdar://problem/52766511>
138
139         Reviewed by Dean Jackson.
140
141         * Configurations/FeatureDefines.xcconfig:
142
143 2019-07-06  Michael Saboff  <msaboff@apple.com>
144
145         switch(String) needs to check for exceptions when resolving the string
146         https://bugs.webkit.org/show_bug.cgi?id=199541
147
148         Reviewed by Mark Lam.
149
150         Added exception checks for resolved Strings in switch processing for all tiers.
151
152         * dfg/DFGOperations.cpp:
153         * jit/JITOperations.cpp:
154         * llint/LLIntSlowPaths.cpp:
155         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
156
157 2019-07-05  Mark Lam  <mark.lam@apple.com>
158
159         ArgumentsEliminationPhase::eliminateCandidatesThatInterfere() should not decrement nodeIndex pass zero.
160         https://bugs.webkit.org/show_bug.cgi?id=199533
161         <rdar://problem/52669111>
162
163         Reviewed by Filip Pizlo.
164
165         * dfg/DFGArgumentsEliminationPhase.cpp:
166
167 2019-07-05  Yusuke Suzuki  <ysuzuki@apple.com>
168
169         Unreviewed, fix build failure on ARM64_32
170         https://bugs.webkit.org/show_bug.cgi?id=182434
171
172         Implicit narrowing from uint64_t to uint32_t happens. We should explicitly narrow it because we already checked
173         the `length` is <= UINT32_MAX.
174
175         * runtime/ArrayPrototype.cpp:
176         (JSC::arrayProtoFuncSpeciesCreate):
177
178 2019-07-05  Alexey Shvayka  <shvaikalesh@gmail.com>
179
180         [JSC] Clean up ArraySpeciesCreate
181         https://bugs.webkit.org/show_bug.cgi?id=182434
182
183         Reviewed by Yusuke Suzuki.
184
185         We have duplicate code in arraySpeciesCreate, filter, map, concatSlowPath of ArrayPrototype.js
186         and speciesConstructArray of ArrayPrototype.cpp. This patch fixes cross-realm Array constructor
187         detection in native speciesConstructArray, upgrades `length` type to correctly handle large integers,
188         and exposes it as @arraySpeciesCreate. Also removes now unused @isArrayConstructor private function.
189         Native speciesConstructArray is preferred because it has fast path via speciesWatchpointIsValid.
190
191         Thoroughly benchmarked: this change progresses ARES-6 by 0-1%.
192
193         * builtins/ArrayPrototype.js:
194         (filter):
195         (map):
196         (globalPrivate.concatSlowPath):
197         (globalPrivate.arraySpeciesCreate): Deleted.
198         * builtins/BuiltinNames.h:
199         * runtime/ArrayConstructor.cpp:
200         (JSC::arrayConstructorPrivateFuncIsArrayConstructor): Deleted.
201         * runtime/ArrayConstructor.h:
202         * runtime/ArrayPrototype.cpp:
203         (JSC::arrayProtoFuncSpeciesCreate):
204         * runtime/ArrayPrototype.h:
205         * runtime/JSGlobalObject.cpp:
206         (JSC::JSGlobalObject::init):
207
208 2019-07-05  Tadeu Zagallo  <tzagallo@apple.com>
209
210         Unreviewed, change the value used to scribble Heap::m_worldState
211         https://bugs.webkit.org/show_bug.cgi?id=199498
212
213         Follow-up after r247160. The value used to scribble should have the
214         conn bit set.
215
216         * heap/Heap.cpp:
217         (JSC::Heap::~Heap):
218
219 2019-07-05  Ryan Haddad  <ryanhaddad@apple.com>
220
221         Unreviewed, rolling out r247115.
222
223         Breaks lldbWebKitTester (and by extension, test-webkitpy)
224
225         Reverted changeset:
226
227         "[WHLSL] Standard library is too big to directly include in
228         WebCore"
229         https://bugs.webkit.org/show_bug.cgi?id=198186
230         https://trac.webkit.org/changeset/247115
231
232 2019-07-05  Tadeu Zagallo  <tzagallo@apple.com>
233
234         Scribble Heap::m_worldState on destructor
235         https://bugs.webkit.org/show_bug.cgi?id=199498
236
237         Reviewed by Sam Weinig.
238
239         The worldState is dumped when we crash due to a failed checkConn, and
240         this will make it clear if the heap has already been destroyed.
241
242         * heap/Heap.cpp:
243         (JSC::Heap::~Heap):
244
245 2019-07-03  Sam Weinig  <weinig@apple.com>
246
247         Adopt simple structured bindings in more places
248         https://bugs.webkit.org/show_bug.cgi?id=199247
249
250         Reviewed by Alex Christensen.
251
252         Replaces simple uses of std::tie() with structured bindings. Does not touch
253         uses of std::tie() that are not initial declarations, use std::ignore or in
254         case where the binding is captured by a lambda, as structured bindings don't
255         work for those cases yet.
256
257         * runtime/PromiseDeferredTimer.cpp:
258         (JSC::PromiseDeferredTimer::doWork):
259         * wasm/WasmFaultSignalHandler.cpp:
260         (JSC::Wasm::trapHandler):
261         * wasm/js/JSWebAssemblyHelpers.h:
262         (JSC::createSourceBufferFromValue):
263         * wasm/js/WebAssemblyPrototype.cpp:
264         (JSC::webAssemblyValidateFunc):
265
266 2019-07-03  Keith Miller  <keith_miller@apple.com>
267
268         PACCage should first cage leaving PAC bits intact then authenticate
269         https://bugs.webkit.org/show_bug.cgi?id=199372
270
271         Reviewed by Saam Barati.
272
273         This ordering prevents someone from taking a signed pointer from
274         outside the gigacage and using it in a struct that expects a caged
275         pointer. Previously, the PACCaging just double checked that the PAC
276         bits were valid for the original pointer.
277
278
279                +---------------------------+
280                |       |        |          |
281                | "PAC" | "base" | "offset" +----+
282                |       |        |          |    |
283                +---------------------------+    | Caging
284                 |                               |
285                 |                               |
286                 |                               v
287                 |                +---------------------------+
288                 |                |       |        |          |
289                 | Bit Merge      | 00000 |  base  | "offset" |
290                 |                |       |        |          |
291                 |                +---------------------------+
292                 |                               |
293                 |                               |
294                 v                               |  Bit Merge
295           +---------------------------+         |
296           |       |        |          |         |
297           | "PAC" |  base  | "offset" +<--------+
298           |       |        |          |
299           +---------------------------+
300                       |
301                       |
302                       | Authenticate
303                       |
304                       v
305           +---------------------------+
306           |       |        |          |
307           | Auth  |  base  | "offset" |
308           |       |        |          |
309           +---------------------------+
310
311         The above ascii art graph shows how the PACCage system works. The
312         key take away is that even if someone passes in a valid, signed
313         pointer outside the cage it will still fail to authenticate as the
314         "base" bits will change before authentication.
315
316
317         * assembler/MacroAssemblerARM64E.h:
318         * assembler/testmasm.cpp:
319         (JSC::testCagePreservesPACFailureBit):
320         * ftl/FTLLowerDFGToB3.cpp:
321         (JSC::FTL::DFG::LowerDFGToB3::caged):
322         * jit/AssemblyHelpers.h:
323         (JSC::AssemblyHelpers::cageConditionally):
324         * llint/LowLevelInterpreter64.asm:
325
326 2019-07-03  Paulo Matos  <pmatos@igalia.com>
327
328         Refactoring of architectural Register Information
329         https://bugs.webkit.org/show_bug.cgi?id=198604
330
331         Reviewed by Keith Miller.
332
333         The goal of this patch is to centralize the register information per platform
334         but access it in a platform independent way. The patch as been implemented for all
335         known platforms: ARM64, ARMv7, MIPS, X86 and X86_64. Register information has
336         been centralized in an architecture per-file: each file is called assembler/<arch>Registers.h.
337
338         RegisterInfo.h is used as a forwarding header to choose which register information to load.
339         assembler/<arch>Assembler.h and jit/RegisterSet.cpp use this information in a platform
340         independent way.
341
342         * CMakeLists.txt:
343         * JavaScriptCore.xcodeproj/project.pbxproj:
344         * assembler/ARM64Assembler.h:
345         (JSC::ARM64Assembler::gprName): Use register names from register info file.
346         (JSC::ARM64Assembler::sprName): likewise.
347         (JSC::ARM64Assembler::fprName): likewise.
348         * assembler/ARM64Registers.h: Added.
349         * assembler/ARMv7Assembler.h:
350         (JSC::ARMv7Assembler::gprName): Use register names from register info file.
351         (JSC::ARMv7Assembler::sprName): likewise.
352         (JSC::ARMv7Assembler::fprName): likewise.
353         * assembler/ARMv7Registers.h: Added.
354         * assembler/MIPSAssembler.h:
355         (JSC::MIPSAssembler::gprName): Use register names from register info file.
356         (JSC::MIPSAssembler::sprName): likewise.
357         (JSC::MIPSAssembler::fprName): likewise.
358         * assembler/MIPSRegisters.h: Added.
359         * assembler/RegisterInfo.h: Added.
360         * assembler/X86Assembler.h:
361         (JSC::X86Assembler::gprName): Use register names from register info file.
362         (JSC::X86Assembler::sprName): likewise.
363         (JSC::X86Assembler::fprName): likewise.
364         * assembler/X86Registers.h: Added.
365         * assembler/X86_64Registers.h: Added.
366         * jit/GPRInfo.h: Fix typo in comment (s/basline/baseline).
367         * jit/RegisterSet.cpp:
368         (JSC::RegisterSet::reservedHardwareRegisters): Use register properties from register info file.
369         (JSC::RegisterSet::calleeSaveRegisters): likewise.
370
371 2019-07-02  Michael Saboff  <msaboff@apple.com>
372
373         Exception from For..of loop destructured assignment eliminates TDZ checks in subsequent code
374         https://bugs.webkit.org/show_bug.cgi?id=199395
375
376         Reviewed by Filip Pizlo.
377
378         For destructuring assignmests, the assignment might throw a reference error if
379         the RHS cannot be coerced.  The current bytecode generated for such assignments
380         optimizes out the TDZ check after the coercible check.
381
382         By saving the current state of the TDZ stack before processing the setting of 
383         target destructured values and then restoring afterwards, we won't optimize out
384         later TDZ check(s).
385
386         A similar change of saving / restoring the TDZ stack where exceptions might
387         happen was done for for..in loops in change set r232219.
388
389         * bytecompiler/NodesCodegen.cpp:
390         (JSC::ObjectPatternNode::bindValue const):
391
392 2019-07-02  Commit Queue  <commit-queue@webkit.org>
393
394         Unreviewed, rolling out r247041.
395         https://bugs.webkit.org/show_bug.cgi?id=199425
396
397         broke some iOS arm64e tests (Requested by keith_miller on
398         #webkit).
399
400         Reverted changeset:
401
402         "PACCage should first cage leaving PAC bits intact then
403         authenticate"
404         https://bugs.webkit.org/show_bug.cgi?id=199372
405         https://trac.webkit.org/changeset/247041
406
407 2019-07-02  Keith Miller  <keith_miller@apple.com>
408
409         Frozen Arrays length assignment should throw in strict mode
410         https://bugs.webkit.org/show_bug.cgi?id=199365
411
412         Reviewed by Yusuke Suzuki.
413
414         * runtime/JSArray.cpp:
415         (JSC::JSArray::put):
416
417 2019-07-02  Paulo Matos  <pmatos@linki.tools>
418
419         Fix typo in if/else block and remove dead assignment
420         https://bugs.webkit.org/show_bug.cgi?id=199352
421
422         Reviewed by Alexey Proskuryakov.
423
424         * yarr/YarrPattern.cpp:
425         (JSC::Yarr::YarrPattern::dumpPattern): Fix typo in if/else block and remove dead assignment
426
427 2019-07-02  Keith Miller  <keith_miller@apple.com>
428
429         PACCage should first cage leaving PAC bits intact then authenticate
430         https://bugs.webkit.org/show_bug.cgi?id=199372
431
432         Reviewed by Saam Barati.
433
434         This ordering prevents someone from taking a signed pointer from
435         outside the gigacage and using it in a struct that expects a caged
436         pointer. Previously, the PACCaging just double checked that the PAC
437         bits were valid for the original pointer.
438
439
440                +---------------------------+
441                |       |        |          |
442                | "PAC" | "base" | "offset" +----+
443                |       |        |          |    |
444                +---------------------------+    | Caging
445                 |                               |
446                 |                               |
447                 |                               v
448                 |                +---------------------------+
449                 |                |       |        |          |
450                 | Bit Merge      | 00000 |  base  | "offset" |
451                 |                |       |        |          |
452                 |                +---------------------------+
453                 |                               |
454                 |                               |
455                 v                               |  Bit Merge
456           +---------------------------+         |
457           |       |        |          |         |
458           | "PAC" |  base  | "offset" +<--------+
459           |       |        |          |
460           +---------------------------+
461                       |
462                       |
463                       | Authenticate
464                       |
465                       v
466           +---------------------------+
467           |       |        |          |
468           | Auth  |  base  | "offset" |
469           |       |        |          |
470           +---------------------------+
471
472         The above ascii art graph shows how the PACCage system works. The
473         key take away is that even if someone passes in a valid, signed
474         pointer outside the cage it will still fail to authenticate as the
475         "base" bits will change before authentication.
476
477
478         * assembler/MacroAssemblerARM64E.h:
479         * assembler/testmasm.cpp:
480         (JSC::testCagePreservesPACFailureBit):
481         * ftl/FTLLowerDFGToB3.cpp:
482         (JSC::FTL::DFG::LowerDFGToB3::caged):
483         * jit/AssemblyHelpers.h:
484         (JSC::AssemblyHelpers::cageConditionally):
485         * llint/LowLevelInterpreter64.asm:
486
487 2019-07-01  Justin Michaud  <justin_michaud@apple.com>
488
489         [Wasm-References] Disable references by default
490         https://bugs.webkit.org/show_bug.cgi?id=199390
491
492         Reviewed by Saam Barati.
493
494         * runtime/Options.h:
495
496 2019-07-01  Ryan Haddad  <ryanhaddad@apple.com>
497
498         Unreviewed, rolling out r246946.
499
500         Caused JSC test crashes on arm64
501
502         Reverted changeset:
503
504         "Add b3 macro lowering for CheckMul on arm64"
505         https://bugs.webkit.org/show_bug.cgi?id=199251
506         https://trac.webkit.org/changeset/246946
507
508 2019-06-28  Justin Michaud  <justin_michaud@apple.com>
509
510         Add b3 macro lowering for CheckMul on arm64
511         https://bugs.webkit.org/show_bug.cgi?id=199251
512
513         Reviewed by Robin Morisset.
514
515         - Lower CheckMul for 32-bit arguments on arm64 into a mul and then an overflow check.
516         - Add a new opcode to air on arm64 for smull (multiplySignExtend32).
517         - Fuse sign extend 32 + mul into smull (taking two 32-bit arguments and producing 64 bits). 
518         - 1.25x speedup on power of two microbenchmark, 1.15x speedup on normal constant microbenchmark, 
519           and no change on the no-constant benchmark.
520         Also, skip some of the b3 tests that were failing before this patch so that the new tests can run
521         to completion.
522
523         * assembler/MacroAssemblerARM64.h:
524         (JSC::MacroAssemblerARM64::multiplySignExtend32):
525         * assembler/testmasm.cpp:
526         (JSC::testMul32SignExtend):
527         (JSC::run):
528         * b3/B3LowerMacros.cpp:
529         * b3/B3LowerToAir.cpp:
530         * b3/air/AirOpcode.opcodes:
531         * b3/testb3.cpp:
532         (JSC::B3::testMulArgs32SignExtend):
533         (JSC::B3::testMulImm32SignExtend):
534         (JSC::B3::testMemoryFence):
535         (JSC::B3::testStoreFence):
536         (JSC::B3::testLoadFence):
537         (JSC::B3::testPinRegisters):
538         (JSC::B3::run):
539
540 2019-06-28  Konstantin Tokarev  <annulen@yandex.ru>
541
542         Remove traces of ENABLE_ICONDATABASE remaining after its removal in 219733
543         https://bugs.webkit.org/show_bug.cgi?id=199317
544
545         Reviewed by Michael Catanzaro.
546
547         While IconDatabase and all code using it was removed,
548         ENABLE_ICONDATABASE still exists as build option and C++ macro.
549
550         * Configurations/FeatureDefines.xcconfig:
551
552 2019-06-27  Mark Lam  <mark.lam@apple.com>
553
554         FTL keepAlive()'s patchpoint should also declare that it reads HeapRange::top().
555         https://bugs.webkit.org/show_bug.cgi?id=199291
556
557         Reviewed by Yusuke Suzuki and Filip Pizlo.
558
559         The sole purpose of keepAlive() is to communicate to B3 that an LValue
560         needs to be kept alive past the last opportunity for a GC.  The only way
561         we can get a GC is via a function call.  Hence, what keepAlive() really
562         needs to communicate is that the LValue needs to be kept alive past the
563         last function call.  Function calls read and write HeapRange::top().
564         Currently, B3 does not shuffle writes.  Hence, simply inserting the
565         keepAlive() after the calls that can GC is sufficient.
566
567         But to be strictly correct, keepAlive() should also declare that it reads
568         HeapRange::top().  This will guarantee that the keepAlive patchpoint won't
569         ever be moved before the function call should B3 gain the ability to shuffle
570         writes in the future.
571
572         * ftl/FTLLowerDFGToB3.cpp:
573         (JSC::FTL::DFG::LowerDFGToB3::keepAlive):
574
575 2019-06-27  Beth Dakin  <bdakin@apple.com>
576
577         Upstream use of MACCATALYST
578         https://bugs.webkit.org/show_bug.cgi?id=199245
579         rdar://problem/51687723
580
581         Reviewed by Tim Horton.
582
583         * Configurations/Base.xcconfig:
584         * Configurations/FeatureDefines.xcconfig:
585         * Configurations/JavaScriptCore.xcconfig:
586         * Configurations/SDKVariant.xcconfig:
587
588 2019-06-27  Saam Barati  <sbarati@apple.com>
589
590         Make WEBGPU enabled only on Mojave and later.
591
592         Rubber-stamped by Myles C. Maxfield.
593
594         * Configurations/FeatureDefines.xcconfig:
595
596 2019-06-27  Don Olmstead  <don.olmstead@sony.com>
597
598         [FTW] Build JavaScriptCore
599         https://bugs.webkit.org/show_bug.cgi?id=199254
600
601         Reviewed by Brent Fulgham.
602
603         * PlatformFTW.cmake: Added.
604
605 2019-06-27  Konstantin Tokarev  <annulen@yandex.ru>
606
607         Use JSC_GLIB_API_ENABLED instead of USE(GLIB) as a compile-time check for GLib JSC API
608         https://bugs.webkit.org/show_bug.cgi?id=199270
609
610         Reviewed by Michael Catanzaro.
611
612         This change allows building code with enabled USE(GLIB) but without
613         GLib JSC API.
614
615         * heap/Heap.cpp:
616         (JSC::Heap::releaseDelayedReleasedObjects):
617         * heap/Heap.h:
618         * heap/HeapInlines.h:
619
620 2019-06-27  Devin Rousso  <drousso@apple.com>
621
622         Web Inspector: throw an error if console.count/console.countReset is called with an object that throws an error from toString
623         https://bugs.webkit.org/show_bug.cgi?id=199252
624
625         Reviewed by Joseph Pecoraro.
626
627         Parse the arguments passed to `console.count` and `console.countReset` before sending it to
628         the `ConsoleClient` so that an error can be thrown if the first argument doesn't `toString`
629         nicely (e.g. without throwing an error).
630
631         Generate call stacks for `console.countReset` to match other `console` methods. Also do this
632         for `console.time`, `console.timeLog`, and `console.timeEnd`. Limit the call stack to only
633         have the top frame, so no unnecessary/extra data is sent to the frontend (right now, only
634         the call location is displayed).
635
636         Rename `title` to `label` for `console.time`, `console.timeLog`, and `console.timeEnd` to
637         better match the spec.
638
639         * runtime/ConsoleClient.h:
640         * runtime/ConsoleObject.cpp:
641         (JSC::valueOrDefaultLabelString):
642         (JSC::consoleProtoFuncCount):
643         (JSC::consoleProtoFuncCountReset):
644         (JSC::consoleProtoFuncTime):
645         (JSC::consoleProtoFuncTimeLog):
646         (JSC::consoleProtoFuncTimeEnd):
647
648         * inspector/JSGlobalObjectConsoleClient.h:
649         * inspector/JSGlobalObjectConsoleClient.cpp:
650         (Inspector::JSGlobalObjectConsoleClient::count):
651         (Inspector::JSGlobalObjectConsoleClient::countReset):
652         (Inspector::JSGlobalObjectConsoleClient::time):
653         (Inspector::JSGlobalObjectConsoleClient::timeLog):
654         (Inspector::JSGlobalObjectConsoleClient::timeEnd):
655
656         * inspector/agents/InspectorConsoleAgent.h:
657         * inspector/agents/InspectorConsoleAgent.cpp:
658         (Inspector::InspectorConsoleAgent::startTiming):
659         (Inspector::InspectorConsoleAgent::logTiming):
660         (Inspector::InspectorConsoleAgent::stopTiming):
661         (Inspector::InspectorConsoleAgent::count):
662         (Inspector::InspectorConsoleAgent::countReset):
663         (Inspector::InspectorConsoleAgent::getCounterLabel): Deleted.
664
665         * inspector/ConsoleMessage.h:
666         * inspector/ConsoleMessage.cpp:
667         (Inspector::ConsoleMessage::ConsoleMessage):
668         Allow `ConsoleMessage`s to be created with both `ScriptArguments` and a `ScriptCallStack`.
669
670 2019-06-27  Fujii Hironori  <Hironori.Fujii@sony.com>
671
672         [CMake] Bump cmake_minimum_required version to 3.10
673         https://bugs.webkit.org/show_bug.cgi?id=199181
674
675         Reviewed by Don Olmstead.
676
677         * CMakeLists.txt:
678
679 2019-06-26  Basuke Suzuki  <Basuke.Suzuki@sony.com>
680
681         [RemoteInspector] Add address argument to listen for RemoteInspectorServer Socket implementation.
682         https://bugs.webkit.org/show_bug.cgi?id=199035
683
684         Reviewed by Ross Kirsling.
685
686         Added new argument `address` to start listening. 
687
688         * inspector/remote/socket/RemoteInspectorServer.cpp:
689         (Inspector::RemoteInspectorServer::start):
690         * inspector/remote/socket/RemoteInspectorServer.h:
691         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
692         (Inspector::Socket::listen):
693         * inspector/remote/socket/win/RemoteInspectorSocketWin.cpp:
694         (Inspector::Socket::listen):
695
696 2019-06-26  Keith Miller  <keith_miller@apple.com>
697
698         speciesConstruct needs to throw if the result is a DataView
699         https://bugs.webkit.org/show_bug.cgi?id=199231
700
701         Reviewed by Mark Lam.
702
703         Previously, we only checked that the result was a
704         JSArrayBufferView, which can include DataViews. This is incorrect
705         as the result should be only be a TypedArray.
706
707         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
708         (JSC::speciesConstruct):
709
710 2019-06-26  Joseph Pecoraro  <pecoraro@apple.com>
711
712         Web Inspector: Implement console.countReset
713         https://bugs.webkit.org/show_bug.cgi?id=199200
714
715         Reviewed by Devin Rousso.
716
717         * inspector/JSGlobalObjectConsoleClient.cpp:
718         (Inspector::JSGlobalObjectConsoleClient::countReset):
719         * inspector/JSGlobalObjectConsoleClient.h:
720         * inspector/agents/InspectorConsoleAgent.cpp:
721         (Inspector::InspectorConsoleAgent::getCounterLabel):
722         (Inspector::InspectorConsoleAgent::count):
723         (Inspector::InspectorConsoleAgent::countReset):
724         * inspector/agents/InspectorConsoleAgent.h:
725         * runtime/ConsoleClient.h:
726         * runtime/ConsoleObject.cpp:
727         (JSC::ConsoleObject::finishCreation):
728         (JSC::consoleProtoFuncCountReset):
729
730 2019-06-26  Keith Miller  <keith_miller@apple.com>
731
732         remove unneeded didBecomePrototype() calls
733         https://bugs.webkit.org/show_bug.cgi?id=199221
734
735         Reviewed by Saam Barati.
736
737         Since we now set didBecomePrototype in Structure::create we don't
738         need to set it expliticly in most of our finishCreation
739         methods. The only exception to this is object prototype, which we
740         set as the prototype of function prototype late (via
741         setPrototypeWithoutTransition).
742
743         * inspector/JSInjectedScriptHostPrototype.cpp:
744         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
745         * inspector/JSJavaScriptCallFramePrototype.cpp:
746         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
747         * runtime/ArrayIteratorPrototype.cpp:
748         (JSC::ArrayIteratorPrototype::finishCreation):
749         * runtime/ArrayPrototype.cpp:
750         (JSC::ArrayPrototype::finishCreation):
751         * runtime/AsyncFromSyncIteratorPrototype.cpp:
752         (JSC::AsyncFromSyncIteratorPrototype::finishCreation):
753         * runtime/AsyncFunctionPrototype.cpp:
754         (JSC::AsyncFunctionPrototype::finishCreation):
755         * runtime/AsyncGeneratorFunctionPrototype.cpp:
756         (JSC::AsyncGeneratorFunctionPrototype::finishCreation):
757         * runtime/AsyncGeneratorPrototype.cpp:
758         (JSC::AsyncGeneratorPrototype::finishCreation):
759         * runtime/AsyncIteratorPrototype.cpp:
760         (JSC::AsyncIteratorPrototype::finishCreation):
761         * runtime/GeneratorFunctionPrototype.cpp:
762         (JSC::GeneratorFunctionPrototype::finishCreation):
763         * runtime/GeneratorPrototype.cpp:
764         (JSC::GeneratorPrototype::finishCreation):
765         * runtime/IteratorPrototype.cpp:
766         (JSC::IteratorPrototype::finishCreation):
767         * runtime/JSGlobalObject.cpp:
768         (JSC::JSGlobalObject::init):
769         * runtime/MapIteratorPrototype.cpp:
770         (JSC::MapIteratorPrototype::finishCreation):
771         * runtime/MapPrototype.cpp:
772         (JSC::MapPrototype::finishCreation):
773         * runtime/ObjectPrototype.cpp:
774         (JSC::ObjectPrototype::finishCreation):
775         * runtime/RegExpStringIteratorPrototype.cpp:
776         (JSC::RegExpStringIteratorPrototype::finishCreation):
777         * runtime/SetIteratorPrototype.cpp:
778         (JSC::SetIteratorPrototype::finishCreation):
779         * runtime/SetPrototype.cpp:
780         (JSC::SetPrototype::finishCreation):
781         * runtime/StringIteratorPrototype.cpp:
782         (JSC::StringIteratorPrototype::finishCreation):
783         * runtime/WeakMapPrototype.cpp:
784         (JSC::WeakMapPrototype::finishCreation):
785         * runtime/WeakObjectRefPrototype.cpp:
786         (JSC::WeakObjectRefPrototype::finishCreation):
787         * runtime/WeakSetPrototype.cpp:
788         (JSC::WeakSetPrototype::finishCreation):
789
790 2019-06-25  Keith Miller  <keith_miller@apple.com>
791
792         Structure::create should call didBecomePrototype()
793         https://bugs.webkit.org/show_bug.cgi?id=196315
794
795         Reviewed by Filip Pizlo.
796
797         Structure::create should also assert that the indexing type makes sense
798         for the prototype being used.
799
800         * runtime/JSObject.h:
801         * runtime/Structure.cpp:
802         (JSC::Structure::isValidPrototype):
803         (JSC::Structure::changePrototypeTransition):
804         * runtime/Structure.h:
805         (JSC::Structure::create): Deleted.
806         * runtime/StructureInlines.h:
807         (JSC::Structure::create):
808         (JSC::Structure::setPrototypeWithoutTransition):
809
810 2019-06-25  Joseph Pecoraro  <pecoraro@apple.com>
811
812         Web Inspector: Implement console.timeLog
813         https://bugs.webkit.org/show_bug.cgi?id=199184
814
815         Reviewed by Devin Rousso.
816
817         * inspector/JSGlobalObjectConsoleClient.cpp:
818         (Inspector::JSGlobalObjectConsoleClient::timeLog):
819         * inspector/JSGlobalObjectConsoleClient.h:
820         * inspector/agents/InspectorConsoleAgent.cpp:
821         (Inspector::InspectorConsoleAgent::logTiming):
822         (Inspector::InspectorConsoleAgent::stopTiming):
823         * inspector/agents/InspectorConsoleAgent.h:
824         * runtime/ConsoleClient.h:
825         * runtime/ConsoleObject.cpp:
826         (JSC::ConsoleObject::finishCreation):
827         (JSC::consoleProtoFuncTimeLog):
828
829 2019-06-25  Michael Catanzaro  <mcatanzaro@igalia.com>
830
831         REGRESSION(r245586): static assertion failed: Match result and EncodedMatchResult should be the same size
832         https://bugs.webkit.org/show_bug.cgi?id=198518
833
834         Reviewed by Keith Miller.
835
836         r245586 made some bad assumptions about the size of size_t, which we can solve using the
837         CPU(ADDRESS32) guard that I didn't know about.
838
839         This solution was developed by Mark Lam and Keith Miller. I'm just preparing the patch.
840
841         * runtime/MatchResult.h:
842
843 2019-06-24  Commit Queue  <commit-queue@webkit.org>
844
845         Unreviewed, rolling out r246714.
846         https://bugs.webkit.org/show_bug.cgi?id=199179
847
848         revert to do patch in a different way. (Requested by keith_mi_
849         on #webkit).
850
851         Reverted changeset:
852
853         "All prototypes should call didBecomePrototype()"
854         https://bugs.webkit.org/show_bug.cgi?id=196315
855         https://trac.webkit.org/changeset/246714
856
857 2019-06-24  Alexey Shvayka  <shvaikalesh@gmail.com>
858
859         Add Array.prototype.{flat,flatMap} to unscopables
860         https://bugs.webkit.org/show_bug.cgi?id=194322
861
862         Reviewed by Keith Miller.
863
864         * runtime/ArrayPrototype.cpp:
865         (JSC::ArrayPrototype::finishCreation):
866
867 2019-06-24  Mark Lam  <mark.lam@apple.com>
868
869         ArraySlice needs to keep the source array alive.
870         https://bugs.webkit.org/show_bug.cgi?id=197374
871         <rdar://problem/50304429>
872
873         Reviewed by Michael Saboff and Filip Pizlo.
874
875         The implementation of the FTL ArraySlice intrinsics may GC while allocating the
876         result array and its butterfly.  Previously, ArraySlice already keeps the source
877         butterfly alive in order to copy from it to the new butterfly after the allocation.
878         Unfortunately, this is not enough.  We also need to keep the source array alive
879         so that GC will scan the values in the butterfly as well.  Note: the butterfly
880         does not have a visitChildren() method to do this scan.  It's the parent object's
881         responsibility to do the scanning.
882
883         This patch fixes this by introducing a keepAlive() utility method, and we use it
884         to keep the source array alive while allocating the result array and butterfly.
885
886         keepAlive() works by using a patchpoint to communicate to B3 that a value (the
887         source array in this case) is still in use.  It also uses a fence to keep B3 from
888         relocating the patchpoint, which may defeat the fix.
889
890         For the DFG's SpeculativeJIT::compileArraySlice(), we may have lucked out and the
891         source array cell is kept alive.  This patch makes it explicit that we should
892         keep its cell alive till after the result array has been allocated.
893
894         For the Baseline JIT and LLInt, we use the arrayProtoFuncSlice() runtime function
895         and there is no issue because the source array (in "thisObj") is in the element
896         copying loop that follows the allocation of the result array.  However, for
897         documentation purposes, this patch adds a call to HeapCell::use() to indicate that
898         the source array need to kept alive at least until after the allocation of the
899         result array.
900
901         * dfg/DFGSpeculativeJIT.cpp:
902         (JSC::DFG::SpeculativeJIT::compileArraySlice):
903         * ftl/FTLLowerDFGToB3.cpp:
904         (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
905         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
906         (JSC::FTL::DFG::LowerDFGToB3::keepAlive):
907         * runtime/ArrayPrototype.cpp:
908         (JSC::arrayProtoFuncSlice):
909
910 2019-06-22  Robin Morisset  <rmorisset@apple.com> and Yusuke Suzuki  <ysuzuki@apple.com>
911
912         All prototypes should call didBecomePrototype()
913         https://bugs.webkit.org/show_bug.cgi?id=196315
914
915         Reviewed by Saam Barati.
916
917         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
918
919         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
920         create structures with invalid prototypes.
921         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
922         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
923
924         * runtime/BigIntPrototype.cpp:
925         (JSC::BigIntPrototype::finishCreation):
926         * runtime/BooleanPrototype.cpp:
927         (JSC::BooleanPrototype::finishCreation):
928         * runtime/DatePrototype.cpp:
929         (JSC::DatePrototype::finishCreation):
930         * runtime/ErrorConstructor.cpp:
931         (JSC::ErrorConstructor::finishCreation):
932         * runtime/ErrorPrototype.cpp:
933         (JSC::ErrorPrototype::finishCreation):
934         * runtime/FunctionConstructor.cpp:
935         (JSC::FunctionConstructor::finishCreation):
936         * runtime/FunctionPrototype.cpp:
937         (JSC::FunctionPrototype::finishCreation):
938         * runtime/IntlCollatorPrototype.cpp:
939         (JSC::IntlCollatorPrototype::finishCreation):
940         * runtime/IntlDateTimeFormatPrototype.cpp:
941         (JSC::IntlDateTimeFormatPrototype::finishCreation):
942         * runtime/IntlNumberFormatPrototype.cpp:
943         (JSC::IntlNumberFormatPrototype::finishCreation):
944         * runtime/IntlPluralRulesPrototype.cpp:
945         (JSC::IntlPluralRulesPrototype::finishCreation):
946         * runtime/JSArrayBufferPrototype.cpp:
947         (JSC::JSArrayBufferPrototype::finishCreation):
948         * runtime/JSDataViewPrototype.cpp:
949         (JSC::JSDataViewPrototype::finishCreation):
950         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
951         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
952         * runtime/JSGlobalObject.cpp:
953         (JSC::createConsoleProperty):
954         * runtime/JSPromisePrototype.cpp:
955         (JSC::JSPromisePrototype::finishCreation):
956         * runtime/JSTypedArrayViewConstructor.cpp:
957         (JSC::JSTypedArrayViewConstructor::finishCreation):
958         * runtime/JSTypedArrayViewPrototype.cpp:
959         (JSC::JSTypedArrayViewPrototype::finishCreation):
960         * runtime/NumberPrototype.cpp:
961         (JSC::NumberPrototype::finishCreation):
962         * runtime/RegExpPrototype.cpp:
963         (JSC::RegExpPrototype::finishCreation):
964         * runtime/StringPrototype.cpp:
965         (JSC::StringPrototype::finishCreation):
966         * runtime/Structure.cpp:
967         (JSC::Structure::isValidPrototype):
968         (JSC::Structure::changePrototypeTransition):
969         * runtime/Structure.h:
970         * runtime/StructureInlines.h:
971         (JSC::Structure::setPrototypeWithoutTransition):
972         * runtime/SymbolPrototype.cpp:
973         (JSC::SymbolPrototype::finishCreation):
974         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
975         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
976         * wasm/js/WebAssemblyInstancePrototype.cpp:
977         (JSC::WebAssemblyInstancePrototype::finishCreation):
978         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
979         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
980         * wasm/js/WebAssemblyMemoryPrototype.cpp:
981         (JSC::WebAssemblyMemoryPrototype::finishCreation):
982         * wasm/js/WebAssemblyModulePrototype.cpp:
983         (JSC::WebAssemblyModulePrototype::finishCreation):
984         * wasm/js/WebAssemblyPrototype.cpp:
985         (JSC::WebAssemblyPrototype::finishCreation):
986         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
987         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
988         * wasm/js/WebAssemblyTablePrototype.cpp:
989         (JSC::WebAssemblyTablePrototype::finishCreation):
990
991 2019-06-22  Yusuke Suzuki  <ysuzuki@apple.com>
992
993         [JSC] Strict, Sloppy and Arrow functions should have different classInfo
994         https://bugs.webkit.org/show_bug.cgi?id=197631
995
996         Reviewed by Saam Barati.
997
998         If a constructor inherits a builtin class, it creates a Structure which is subclassing the builtin class.
999         This is done by using InternalFunction::createSubclassStructure. But to accelerate the common cases, we
1000         cache the created structure in InternalFunctionAllocationProfile. Whether the cache is valid is checked
1001         by comparing classInfo of the cached structure and the given base structure. This implicitly assume that
1002         each builtin class's InternalFunction creates an instance based on one structure.
1003
1004         However, Function constructor is an exception: Function constructor creates an instance which has different
1005         structures based on a parameter. If a strict code is given (e.g. "'use strict'"), it creates a function
1006         instance with strict function structure.
1007
1008         As a result, InternalFunctionAllocationProfile incorrectly caches the structure. Consider the following code.
1009
1010             class A extends Function { };
1011             let a = new A("'use strict'");
1012             let b = new A("");
1013
1014         While `a` and `b` should have different structures, `A` caches the structure for `a`, and reuse it even the given
1015         code is not a strict code. This is problematic: We are separating structures of strict, sloppy, and arrow functions
1016         because they have different properties. However, in the above case, a and b have the same structure while they have
1017         different properties. So it causes incorrect structure-based caching in JSC. One of the example is HasOwnPropertyCache.
1018
1019         In this patch, we introduce JSStrictFunction, JSSloppyFunction, and JSArrowFunction classes and classInfos. This design
1020         works well and already partially accepted for JSGeneratorFunction, JSAsyncGeneratorFunction, and JSAsyncFunction. Each
1021         structure now has a different classInfo so that InternalFunctionAllocationProfile correctly caches and invalidates the
1022         cached one based on the classInfo. Since we already have different structures for these instances, and DFG and FTL
1023         optimizations are based on JSFunctionType (not classInfo), introducing these three classInfo do not break the optimization.
1024
1025         Note that structures on ArrayConstructor does not cause the same problem. It only uses Undecided indexing typed array
1026         structure in InternalFunctionAllocationProfile, and once haveABadTime happens, it clears InternalFunctionAllocationProfile.
1027
1028         * runtime/JSAsyncFunction.h: This subspaceFor is not necessary since it is defined in JSFunction. And we already ensure that
1029         sizeof(JSAsyncFunction) == sizeof(JSFunction).
1030         * runtime/JSAsyncGeneratorFunction.cpp:
1031         * runtime/JSAsyncGeneratorFunction.h: Ditto.
1032         * runtime/JSFunction.cpp:
1033         * runtime/JSFunction.h:
1034         * runtime/JSGeneratorFunction.h: Ditto.
1035         * runtime/JSGlobalObject.cpp:
1036         (JSC::JSGlobalObject::init):
1037
1038 2019-06-22  Yusuke Suzuki  <ysuzuki@apple.com>
1039
1040         [JSC] ClassExpr should not store result in the middle of evaluation
1041         https://bugs.webkit.org/show_bug.cgi?id=199106
1042
1043         Reviewed by Tadeu Zagallo.
1044
1045         Let's consider the case,
1046
1047             let a = class A {
1048                 static get[a=0x12345678]() {
1049                 }
1050             };
1051
1052         When evaluating `class A` expression, we should not use the local register for `let a`
1053         until we finally store it to that register. Otherwise, `a=0x12345678` will override it.
1054         Out BytecodeGenerator does that this by using tempDestination and finalDestination, but
1055         we did not do that in ClassExprNode.
1056
1057         This patch leverages tempDestination and finalDestination to store `class A` result finally,
1058         while we attempt to reduce mov.
1059
1060         * bytecompiler/NodesCodegen.cpp:
1061         (JSC::ClassExprNode::emitBytecode):
1062
1063 2019-06-21  Sihui Liu  <sihui_liu@apple.com>
1064
1065         openDatabase should return an empty object when WebSQL is disabled
1066         https://bugs.webkit.org/show_bug.cgi?id=198805
1067
1068         Reviewed by Geoffrey Garen.
1069
1070         * runtime/JSFunction.cpp:
1071         (JSC::JSFunction::createFunctionThatMasqueradesAsUndefined):
1072         * runtime/JSFunction.h:
1073
1074 2019-06-21  Alexey Shvayka  <shvaikalesh@gmail.com>
1075
1076         Remove extra check in RegExp @matchSlow
1077         https://bugs.webkit.org/show_bug.cgi?id=198846
1078
1079         Reviewed by Joseph Pecoraro.
1080
1081         Type of RegExp `exec` result is already asserted in @regExpExec.
1082
1083         * builtins/RegExpPrototype.js:
1084         (globalPrivate.matchSlow): Remove isObject check.
1085
1086 2019-06-20  Justin Michaud  <justin_michaud@apple.com>
1087
1088         [WASM-References] Add extra tests for Wasm references + fix element parsing and subtyping bugs
1089         https://bugs.webkit.org/show_bug.cgi?id=199044
1090
1091         Reviewed by Saam Barati.
1092
1093         Fix parsing table indices from the element section. The byte that we previously read as the table index actually tells us how to parse the table index.
1094         Fix some areas where we got the isSubtype check wrong, causing funcrefs to not be considred anyrefs.
1095
1096         * wasm/WasmAirIRGenerator.cpp:
1097         (JSC::Wasm::AirIRGenerator::unify):
1098         * wasm/WasmSectionParser.cpp:
1099         (JSC::Wasm::SectionParser::parseElement):
1100         * wasm/WasmValidate.cpp:
1101         (JSC::Wasm::Validate::unify):
1102
1103 2019-06-18  Darin Adler  <darin@apple.com>
1104
1105         Tidy up the remaining bits of the AtomicString to AtomString rename
1106         https://bugs.webkit.org/show_bug.cgi?id=198990
1107
1108         Reviewed by Michael Catanzaro.
1109
1110         * dfg/DFGSpeculativeJIT.cpp:
1111         (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage): Use flagIsAtom.
1112         * dfg/DFGSpeculativeJIT32_64.cpp:
1113         (JSC::DFG::SpeculativeJIT::compile): Ditto.
1114         * dfg/DFGSpeculativeJIT64.cpp:
1115         (JSC::DFG::SpeculativeJIT::compile): Ditto.
1116         * ftl/FTLLowerDFGToB3.cpp:
1117         (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty): Ditto.
1118         (JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent): Ditto.
1119
1120 2019-06-19  Alexey Shvayka  <shvaikalesh@gmail.com>
1121
1122         Optimize `resolve` method lookup in Promise static methods
1123         https://bugs.webkit.org/show_bug.cgi?id=198864
1124
1125         Reviewed by Yusuke Suzuki.
1126
1127         Lookup `resolve` method only once in Promise.{all,allSettled,race}.
1128         (https://github.com/tc39/ecma262/pull/1506)
1129
1130         Already implemented in V8.
1131
1132         * builtins/PromiseConstructor.js:
1133
1134 2019-06-19  Tadeu Zagallo  <tzagallo@apple.com>
1135
1136         Some of the ASSERTs in CachedTypes.cpp should be RELEASE_ASSERTs
1137         https://bugs.webkit.org/show_bug.cgi?id=199030
1138
1139         Reviewed by Mark Lam.
1140
1141         These assertions represent strong assumptions that the cache makes so
1142         it's not safe to keep executing if they fail.
1143
1144         * runtime/CachedTypes.cpp:
1145         (JSC::Encoder::malloc):
1146         (JSC::Encoder::Page::alignEnd):
1147         (JSC::Decoder::ptrForOffsetFromBase):
1148         (JSC::Decoder::handleForEnvironment const):
1149         (JSC::Decoder::setHandleForEnvironment):
1150         (JSC::CachedPtr::get const):
1151         (JSC::CachedOptional::encode):
1152         (JSC::CachedOptional::decodeAsPtr const): Deleted.
1153
1154 2019-06-19  Adrian Perez de Castro  <aperez@igalia.com>
1155
1156         [WPE][GTK] Fix build with unified sources disabled
1157         https://bugs.webkit.org/show_bug.cgi?id=198752
1158
1159         Reviewed by Michael Catanzaro.
1160
1161         * runtime/WeakObjectRefConstructor.h: Add missing inclusion of InternalFunction.h
1162         and forward declaration of WeakObjectRefPrototype.
1163         * wasm/js/WebAssemblyFunction.cpp: Add missing inclusion of JSWebAssemblyHelpers.h
1164
1165 2019-06-19  Justin Michaud  <justin_michaud@apple.com>
1166
1167         [WASM-References] Rename anyfunc to funcref
1168         https://bugs.webkit.org/show_bug.cgi?id=198983
1169
1170         Reviewed by Yusuke Suzuki.
1171
1172         Anyfunc should become funcref since it was renamed in the spec. We should also support the string 'anyfunc' in the table constructor since this is 
1173         the only non-binary-format place where it is exposed to users.
1174
1175         * wasm/WasmAirIRGenerator.cpp:
1176         (JSC::Wasm::AirIRGenerator::gFuncref):
1177         (JSC::Wasm::AirIRGenerator::tmpForType):
1178         (JSC::Wasm::AirIRGenerator::emitCCall):
1179         (JSC::Wasm::AirIRGenerator::moveOpForValueType):
1180         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
1181         (JSC::Wasm::AirIRGenerator::addLocal):
1182         (JSC::Wasm::AirIRGenerator::addConstant):
1183         (JSC::Wasm::AirIRGenerator::addRefFunc):
1184         (JSC::Wasm::AirIRGenerator::addReturn):
1185         (JSC::Wasm::AirIRGenerator::gAnyfunc): Deleted.
1186         * wasm/WasmCallingConvention.h:
1187         (JSC::Wasm::CallingConventionAir::marshallArgument const):
1188         (JSC::Wasm::CallingConventionAir::setupCall const):
1189         * wasm/WasmExceptionType.h:
1190         * wasm/WasmFormat.h:
1191         (JSC::Wasm::isValueType):
1192         (JSC::Wasm::isSubtype):
1193         (JSC::Wasm::TableInformation::wasmType const):
1194         * wasm/WasmFunctionParser.h:
1195         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1196         * wasm/WasmSectionParser.cpp:
1197         (JSC::Wasm::SectionParser::parseTableHelper):
1198         (JSC::Wasm::SectionParser::parseElement):
1199         (JSC::Wasm::SectionParser::parseInitExpr):
1200         * wasm/WasmValidate.cpp:
1201         (JSC::Wasm::Validate::addRefFunc):
1202         * wasm/js/JSToWasm.cpp:
1203         (JSC::Wasm::createJSToWasmWrapper):
1204         * wasm/js/WasmToJS.cpp:
1205         (JSC::Wasm::wasmToJS):
1206         * wasm/js/WebAssemblyFunction.cpp:
1207         (JSC::callWebAssemblyFunction):
1208         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1209         * wasm/js/WebAssemblyModuleRecord.cpp:
1210         (JSC::WebAssemblyModuleRecord::link):
1211         * wasm/js/WebAssemblyTableConstructor.cpp:
1212         (JSC::constructJSWebAssemblyTable):
1213         * wasm/wasm.json:
1214
1215 2019-06-19  Fujii Hironori  <Hironori.Fujii@sony.com>
1216
1217         [CMake][Win] CombinedDomains.json is generated twice in JavaScriptCore_CopyPrivateHeaders and JavaScriptCore projects
1218         https://bugs.webkit.org/show_bug.cgi?id=198853
1219
1220         Reviewed by Don Olmstead.
1221
1222         JavaScriptCore_CopyPrivateHeaders target needs to have a direct or
1223         indirect dependency of JavaScriptCore target for CMake Visual
1224         Studio generator to eliminate duplicated custom commands.
1225
1226         * CMakeLists.txt: Added JavaScriptCore as a dependency of JavaScriptCore_CopyPrivateHeaders.
1227
1228 2019-06-18  Yusuke Suzuki  <ysuzuki@apple.com>
1229
1230         [JSC] JSLock should be WebThread aware
1231         https://bugs.webkit.org/show_bug.cgi?id=198911
1232
1233         Reviewed by Geoffrey Garen.
1234
1235         Since WebKitLegacy content rendering is done in WebThread instead of the main thread in iOS, user of WebKitLegacy (e.g. UIWebView) needs
1236         to grab the WebThread lock (which is a recursive lock) in the main thread when touching the WebKitLegacy content.
1237         But, WebKitLegacy can expose JSContext for the web view. And we can interact with the JS content through JavaScriptCore APIs. However,
1238         since WebThread is a concept in WebCore, JavaScriptCore APIs do not grab the WebThread lock. As a result, WebKitLegacy web content can be
1239         modified from the main thread without grabbing the WebThread lock through JavaScriptCore APIs.
1240
1241         This patch makes JSC aware of WebThread: JSLock grabs the WebThread lock before grabbing JS's lock. While this seems layering violation,
1242         we already have many USE(WEB_THREAD) and WebThread aware code in WTF. Eventually, we should move WebThread code from WebCore to WTF since
1243         JSC and WTF need to be aware of WebThread. But, for now, we just use the function pointer exposed by WebCore.
1244
1245         Since both JSLock and the WebThread lock are recursive locks, nested locking is totally OK. The possible problem is the order of locking.
1246         We ensure that we always grab locks in (1) the WebThread lock and (2) JSLock order.
1247
1248         In JSLock, we take the WebThread lock, but we do not unlock it. This is how we use the WebThread lock: the WebThread lock is released
1249         automatically when RunLoop finishes the current cycle, and in WebKitLegacy, we do not call unlocking function of the WebThread lock except
1250         for some edge cases.
1251
1252         * API/JSVirtualMachine.mm:
1253         (-[JSVirtualMachine isWebThreadAware]):
1254         * API/JSVirtualMachineInternal.h:
1255         * runtime/JSLock.cpp:
1256         (JSC::JSLockHolder::JSLockHolder):
1257         (JSC::JSLock::lock):
1258         (JSC::JSLockHolder::init): Deleted.
1259         * runtime/JSLock.h:
1260         (JSC::JSLock::makeWebThreadAware):
1261         (JSC::JSLock::isWebThreadAware const):
1262
1263 2019-06-18  Justin Michaud  <justin_michaud@apple.com>
1264
1265         [WASM-References] Add support for Table.size, grow and fill instructions
1266         https://bugs.webkit.org/show_bug.cgi?id=198761
1267
1268         Reviewed by Yusuke Suzuki.
1269
1270         Add support for Table.size, grow and fill instructions. This also required
1271         adding support for two-byte opcodes to the ops generator.
1272
1273         * wasm/WasmAirIRGenerator.cpp:
1274         (JSC::Wasm::AirIRGenerator::gAnyref):
1275         (JSC::Wasm::AirIRGenerator::tmpForType):
1276         (JSC::Wasm::AirIRGenerator::addTableSize):
1277         (JSC::Wasm::AirIRGenerator::addTableGrow):
1278         (JSC::Wasm::AirIRGenerator::addTableFill):
1279         * wasm/WasmB3IRGenerator.cpp:
1280         (JSC::Wasm::B3IRGenerator::addTableSize):
1281         (JSC::Wasm::B3IRGenerator::addTableGrow):
1282         (JSC::Wasm::B3IRGenerator::addTableFill):
1283         * wasm/WasmExceptionType.h:
1284         * wasm/WasmFormat.h:
1285         (JSC::Wasm::TableInformation::wasmType const):
1286         * wasm/WasmFunctionParser.h:
1287         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1288         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
1289         * wasm/WasmInstance.cpp:
1290         (JSC::Wasm::doWasmTableGrow):
1291         (JSC::Wasm::doWasmTableFill):
1292         * wasm/WasmInstance.h:
1293         * wasm/WasmTable.cpp:
1294         (JSC::Wasm::Table::grow):
1295         * wasm/WasmValidate.cpp:
1296         (JSC::Wasm::Validate::addTableSize):
1297         (JSC::Wasm::Validate::addTableGrow):
1298         (JSC::Wasm::Validate::addTableFill):
1299         * wasm/generateWasmOpsHeader.py:
1300         (opcodeMacroizer):
1301         (ExtTableOpType):
1302         * wasm/wasm.json:
1303
1304 2019-06-18  Keith Miller  <keith_miller@apple.com>
1305
1306         Unreviewed, fix signature of currentWeakRefVersion to return an uintptr_t.
1307
1308         * runtime/VM.h:
1309         (JSC::VM::currentWeakRefVersion const):
1310
1311 2019-06-18  Justin Michaud  <justin_michaud@apple.com>
1312
1313         [WASM-References] Add support for multiple tables
1314         https://bugs.webkit.org/show_bug.cgi?id=198760
1315
1316         Reviewed by Saam Barati.
1317
1318         Support multiple wasm tables. We turn tableInformation into a tables array, and update all of the
1319         existing users to give a table index. The array of Tables in Wasm::Instance is hung off the tail
1320         to make it easier to use from jit code. 
1321
1322         * wasm/WasmAirIRGenerator.cpp:
1323         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
1324         (JSC::Wasm::AirIRGenerator::addTableGet):
1325         (JSC::Wasm::AirIRGenerator::addTableSet):
1326         (JSC::Wasm::AirIRGenerator::addCallIndirect):
1327         * wasm/WasmB3IRGenerator.cpp:
1328         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1329         (JSC::Wasm::B3IRGenerator::addTableGet):
1330         (JSC::Wasm::B3IRGenerator::addTableSet):
1331         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1332         * wasm/WasmExceptionType.h:
1333         * wasm/WasmFormat.h:
1334         (JSC::Wasm::Element::Element):
1335         * wasm/WasmFunctionParser.h:
1336         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1337         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
1338         * wasm/WasmInstance.cpp:
1339         (JSC::Wasm::Instance::Instance):
1340         (JSC::Wasm::Instance::create):
1341         (JSC::Wasm::Instance::extraMemoryAllocated const):
1342         (JSC::Wasm::Instance::table):
1343         (JSC::Wasm::Instance::setTable):
1344         * wasm/WasmInstance.h:
1345         (JSC::Wasm::Instance::updateCachedMemory):
1346         (JSC::Wasm::Instance::offsetOfGlobals):
1347         (JSC::Wasm::Instance::offsetOfTablePtr):
1348         (JSC::Wasm::Instance::allocationSize):
1349         (JSC::Wasm::Instance::table): Deleted.
1350         (JSC::Wasm::Instance::setTable): Deleted.
1351         (JSC::Wasm::Instance::offsetOfTable): Deleted.
1352         * wasm/WasmModuleInformation.h:
1353         (JSC::Wasm::ModuleInformation::tableCount const):
1354         * wasm/WasmSectionParser.cpp:
1355         (JSC::Wasm::SectionParser::parseImport):
1356         (JSC::Wasm::SectionParser::parseTableHelper):
1357         (JSC::Wasm::SectionParser::parseTable):
1358         (JSC::Wasm::SectionParser::parseElement):
1359         * wasm/WasmTable.h:
1360         (JSC::Wasm::Table::owner const):
1361         * wasm/WasmValidate.cpp:
1362         (JSC::Wasm::Validate::addTableGet):
1363         (JSC::Wasm::Validate::addTableSet):
1364         (JSC::Wasm::Validate::addCallIndirect):
1365         * wasm/js/JSWebAssemblyInstance.cpp:
1366         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
1367         (JSC::JSWebAssemblyInstance::visitChildren):
1368         * wasm/js/JSWebAssemblyInstance.h:
1369         * wasm/js/WebAssemblyModuleRecord.cpp:
1370         (JSC::WebAssemblyModuleRecord::link):
1371         (JSC::WebAssemblyModuleRecord::evaluate):
1372         * wasm/wasm.json:
1373
1374 2019-06-18  Alexey Shvayka  <shvaikalesh@gmail.com>
1375
1376         [ESNExt] String.prototype.matchAll
1377         https://bugs.webkit.org/show_bug.cgi?id=186694
1378
1379         Reviewed by Yusuke Suzuki.
1380
1381         Implement String.prototype.matchAll.
1382         (https://tc39.es/ecma262/#sec-string.prototype.matchall)
1383
1384         Also rename @globalPrivate @constructor functions and C++ variables holding them.
1385
1386         Shipping in Chrome since version 73.
1387         Shipping in Firefox since version 67.
1388
1389         * CMakeLists.txt:
1390         * DerivedSources-input.xcfilelist:
1391         * DerivedSources.make:
1392         * JavaScriptCore.xcodeproj/project.pbxproj:
1393         * Scripts/wkbuiltins/builtins_generate_combined_header.py:
1394         (get_var_name):
1395         (generate_section_for_global_private_code_name_macro):
1396         * Sources.txt:
1397         * builtins/ArrayPrototype.js:
1398         (globalPrivate.ArrayIterator):
1399         (values):
1400         (keys):
1401         (entries):
1402         (globalPrivate.createArrayIterator): Deleted.
1403         * builtins/AsyncFromSyncIteratorPrototype.js:
1404         (globalPrivate.createAsyncFromSyncIterator):
1405         (globalPrivate.AsyncFromSyncIterator):
1406         (globalPrivate.AsyncFromSyncIteratorConstructor): Deleted.
1407         * builtins/BuiltinNames.h:
1408         * builtins/MapPrototype.js:
1409         (globalPrivate.MapIterator):
1410         (values):
1411         (keys):
1412         (entries):
1413         (globalPrivate.createMapIterator): Deleted.
1414         * builtins/RegExpPrototype.js:
1415         (globalPrivate.RegExpStringIterator):
1416         (overriddenName.string_appeared_here.matchAll):
1417         * builtins/RegExpStringIteratorPrototype.js: Added.
1418         (next):
1419         * builtins/SetPrototype.js:
1420         (globalPrivate.SetIterator):
1421         (values):
1422         (entries):
1423         (globalPrivate.createSetIterator): Deleted.
1424         * builtins/StringPrototype.js:
1425         (matchAll):
1426         * builtins/TypedArrayPrototype.js:
1427         (values):
1428         (keys):
1429         (entries):
1430         * runtime/CommonIdentifiers.h:
1431         * runtime/JSGlobalObject.cpp:
1432         (JSC::JSGlobalObject::init):
1433         * runtime/RegExpPrototype.cpp:
1434         (JSC::RegExpPrototype::finishCreation):
1435         * runtime/RegExpStringIteratorPrototype.cpp: Added.
1436         (JSC::RegExpStringIteratorPrototype::finishCreation):
1437         * runtime/RegExpStringIteratorPrototype.h: Added.
1438         * runtime/StringPrototype.cpp:
1439
1440 2019-06-18  Keith Miller  <keith_miller@apple.com>
1441
1442         Add support for WeakRef
1443         https://bugs.webkit.org/show_bug.cgi?id=198710
1444
1445         Reviewed by Yusuke Suzuki.
1446
1447         Add support for WeakRefs which are now at stage 3
1448         (https://tc39.es/proposal-weakrefs). This patch doesn't add
1449         support for FinalizationGroups, which I'll add in another patch.
1450
1451         Some other things of interest. Per the spec, we cannot collect a
1452         weak refs target unless it has not been dereffed (or created) in
1453         the current microtask turn. i.e. WeakRefs are only allowed to be
1454         collected at the end of a drain of the Microtask queue. My
1455         understanding for this behavior is to reduce implementation
1456         dependence on specific GC behavior in a given browser.
1457
1458         We track if a WeakRef is retaining its target by using a version
1459         number on each WeakRef as well as on the VM. Whenever a WeakRef is
1460         derefed we update its version number to match the VM's then
1461         WriteBarrier ourselves. During marking if the VM and the WeakRef
1462         have the same version number, the target is visited.
1463
1464         * JavaScriptCore.xcodeproj/project.pbxproj:
1465         * Sources.txt:
1466         * heap/Heap.cpp:
1467         (JSC::Heap::finalizeUnconditionalFinalizers):
1468         * jsc.cpp:
1469         (GlobalObject::finishCreation):
1470         (functionReleaseWeakRefs):
1471         * runtime/CommonIdentifiers.h:
1472         * runtime/JSGlobalObject.cpp:
1473         * runtime/JSGlobalObject.h:
1474         * runtime/JSWeakObjectRef.cpp: Added.
1475         (JSC::JSWeakObjectRef::finishCreation):
1476         (JSC::JSWeakObjectRef::visitChildren):
1477         (JSC::JSWeakObjectRef::finalizeUnconditionally):
1478         (JSC::JSWeakObjectRef::toStringName):
1479         * runtime/JSWeakObjectRef.h: Added.
1480         * runtime/VM.cpp:
1481         (JSC::VM::drainMicrotasks):
1482         * runtime/VM.h:
1483         (JSC::VM::setOnEachMicrotaskTick):
1484         (JSC::VM::finalizeSynchronousJSExecution):
1485         (JSC::VM::currentWeakRefVersion const):
1486         * runtime/WeakObjectRefConstructor.cpp: Added.
1487         (JSC::WeakObjectRefConstructor::finishCreation):
1488         (JSC::WeakObjectRefConstructor::WeakObjectRefConstructor):
1489         (JSC::callWeakRef):
1490         (JSC::constructWeakRef):
1491         * runtime/WeakObjectRefConstructor.h: Added.
1492         (JSC::WeakObjectRefConstructor::create):
1493         (JSC::WeakObjectRefConstructor::createStructure):
1494         * runtime/WeakObjectRefPrototype.cpp: Added.
1495         (JSC::WeakObjectRefPrototype::finishCreation):
1496         (JSC::getWeakRef):
1497         (JSC::protoFuncWeakRefDeref):
1498         * runtime/WeakObjectRefPrototype.h: Added.
1499
1500 2019-06-18  Tadeu Zagallo  <tzagallo@apple.com>
1501
1502         Add missing mutator fence in compileNewFunction
1503         https://bugs.webkit.org/show_bug.cgi?id=198849
1504         <rdar://problem/51733890>
1505
1506         Reviewed by Saam Barati.
1507
1508         Follow-up after r246553. Saam pointed out that we still need a mutator
1509         fence before allocating the FunctionRareData, since the allocation
1510         might trigger a slow path call.
1511
1512         * dfg/DFGSpeculativeJIT.cpp:
1513         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
1514         * ftl/FTLLowerDFGToB3.cpp:
1515         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
1516
1517 2019-06-18  Tadeu Zagallo  <tzagallo@apple.com>
1518
1519         DFG code should not reify the names of builtin functions with private names
1520         https://bugs.webkit.org/show_bug.cgi?id=198849
1521         <rdar://problem/51733890>
1522
1523         Reviewed by Filip Pizlo.
1524
1525         Builtin functions that have a private name call setHasReifiedName from finishCreation.
1526         When compiled with DFG and FTL, that does not get called and the function ends up reifying
1527         its name. In order to fix that, we initialize FunctionRareData and set m_hasReifiedName to
1528         true from compileNewFunction in both DFG and FTL.
1529
1530         * bytecode/InternalFunctionAllocationProfile.h:
1531         (JSC::InternalFunctionAllocationProfile::offsetOfStructure):
1532         * bytecode/ObjectAllocationProfile.h:
1533         (JSC::ObjectAllocationProfileWithPrototype::offsetOfPrototype):
1534         * bytecode/UnlinkedFunctionExecutable.h:
1535         * dfg/DFGSpeculativeJIT.cpp:
1536         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
1537         * ftl/FTLAbstractHeapRepository.h:
1538         * ftl/FTLLowerDFGToB3.cpp:
1539         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
1540         * runtime/FunctionExecutable.h:
1541         * runtime/FunctionRareData.h:
1542         * runtime/JSFunction.cpp:
1543         (JSC::JSFunction::finishCreation):
1544         * runtime/JSFunction.h:
1545         * runtime/JSFunctionInlines.h:
1546         (JSC::JSFunction::isAnonymousBuiltinFunction const):
1547
1548 2019-06-18  Keith Miller  <keith_miller@apple.com>
1549
1550         MaybeParseAsGeneratorForScope sometimes loses track of its scope ref
1551         https://bugs.webkit.org/show_bug.cgi?id=198969
1552         <rdar://problem/51620714>
1553
1554         Reviewed by Tadeu Zagallo.
1555
1556         Sometimes if the parser has enough nested scopes
1557         MaybeParseAsGeneratorForScope can lose track of the ScopeRef it
1558         should be tracking. This is because the parser sometimes relocates
1559         its ScopeRefs. To fix this MaybeParseAsGeneratorForScope should
1560         hold the scope ref it's watching.
1561
1562         * parser/Parser.cpp:
1563         (JSC::Scope::MaybeParseAsGeneratorForScope::MaybeParseAsGeneratorForScope):
1564         (JSC::Scope::MaybeParseAsGeneratorForScope::~MaybeParseAsGeneratorForScope):
1565
1566 2019-06-17  Justin Michaud  <justin_michaud@apple.com>
1567
1568         Validate that table element type is funcref if using an element section
1569         https://bugs.webkit.org/show_bug.cgi?id=198910
1570
1571         Reviewed by Yusuke Suzuki.
1572
1573         Add missing validation when attempting to add an element section to an anyref table.
1574
1575         * wasm/WasmSectionParser.cpp:
1576         (JSC::Wasm::SectionParser::parseElement):
1577
1578 2019-06-17  Tadeu Zagallo  <tzagallo@apple.com>
1579
1580         Concurrent GC should check the conn before starting a new collection cycle
1581         https://bugs.webkit.org/show_bug.cgi?id=198913
1582         <rdar://problem/49515149>
1583
1584         Reviewed by Filip Pizlo.
1585
1586         Heap::requestCollection tries to steal the conn as an optimization to avoid waking up the collector
1587         thread if it's idle. We determine if the collector is idle by ensuring that there are no pending collections
1588         and that the current GC phase is NotRunning. However, that's not safe immediately after the concurrent
1589         GC has finished processing the last pending request. The collector thread will runEndPhase and immediately
1590         start runNotRunningPhase, without checking if it still has the conn. If the mutator has stolen the conn in
1591         the mean time, this will lead to both threads collecting concurrently, and eventually we'll crash in checkConn,
1592         since the collector is running but doesn't have the conn anymore.
1593
1594         To solve this, we check if we still have the conn after holding the lock in runNotRunningPhase, in case the mutator
1595         has stolen the conn. Ideally, we wouldn't let the mutator steal the conn in the first place, but that doesn't seem
1596         trivial to determine.
1597
1598         * heap/Heap.cpp:
1599         (JSC::Heap::runNotRunningPhase):
1600
1601 2019-06-17  Yusuke Suzuki  <ysuzuki@apple.com>
1602
1603         [JSC] Introduce DisposableCallSiteIndex to enforce type-safety
1604         https://bugs.webkit.org/show_bug.cgi?id=197378
1605
1606         Reviewed by Saam Barati.
1607
1608         Some of CallSiteIndex are disposable. This is because some of CallSiteIndex are allocated and freed at runtime (not DFG/FTL compile time).
1609         The example is CallSiteIndex for exception handler in GCAwareJITStubRoutineWithExceptionHandler. If we do not allocate and free CallSiteIndex,
1610         we will create a new CallSiteIndex continuously and leak memory.
1611
1612         The other CallSiteIndex are not simply disposable because the ownership model is not unique one. They can be shared between multiple clients.
1613         But not disposing them is OK because they are static one: they are allocated when compiling DFG/FTL, and we do not allocate such CallSiteIndex
1614         at runtime.
1615
1616         To make this difference explicit and avoid disposing non-disposable CallSiteIndex accidentally, we introduce DisposableCallSiteIndex type, and
1617         enforce type-safety to some degree.
1618
1619         We also correctly update the DisposableCallSiteIndex => CodeOrigin table when we are reusing the previously used DisposableCallSiteIndex.
1620
1621         * bytecode/CodeBlock.cpp:
1622         (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
1623         (JSC::CodeBlock::removeExceptionHandlerForCallSite):
1624         * bytecode/CodeBlock.h:
1625         * bytecode/PolymorphicAccess.cpp:
1626         (JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
1627         (JSC::PolymorphicAccess::regenerate):
1628         * bytecode/PolymorphicAccess.h:
1629         (JSC::AccessGenerationState::callSiteIndexForExceptionHandling): Deleted.
1630         * dfg/DFGCommonData.cpp:
1631         (JSC::DFG::CommonData::addUniqueCallSiteIndex):
1632         (JSC::DFG::CommonData::addDisposableCallSiteIndex):
1633         (JSC::DFG::CommonData::removeDisposableCallSiteIndex):
1634         (JSC::DFG::CommonData::removeCallSiteIndex): Deleted.
1635         * dfg/DFGCommonData.h:
1636         * interpreter/CallFrame.h:
1637         (JSC::DisposableCallSiteIndex::DisposableCallSiteIndex):
1638         (JSC::DisposableCallSiteIndex::fromCallSiteIndex):
1639         * jit/GCAwareJITStubRoutine.cpp:
1640         (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
1641         (JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):
1642         (JSC::createJITStubRoutine):
1643         * jit/GCAwareJITStubRoutine.h:
1644         * jit/JITInlineCacheGenerator.h:
1645
1646 2019-06-17  Justin Michaud  <justin_michaud@apple.com>
1647
1648         [WASM-References] Add support for Funcref in parameters and return types
1649         https://bugs.webkit.org/show_bug.cgi?id=198157
1650
1651         Reviewed by Yusuke Suzuki.
1652
1653         Add support for funcref in parameters, globals, and in table.get/set. When converting a JSValue to 
1654         a funcref (nee anyfunc), we first make sure it is an exported wasm function or null. 
1655
1656         We also add support for Ref.func. Anywhere a Ref.func is used, (statically) we construct a JS wrapper
1657         for it so that we never need to construct JSValues when handling references. This should make threads
1658         easier to implement.
1659
1660         Finally, we add some missing bounds checks for table.get/set.
1661
1662         * wasm/WasmAirIRGenerator.cpp:
1663         (JSC::Wasm::AirIRGenerator::tmpForType):
1664         (JSC::Wasm::AirIRGenerator::moveOpForValueType):
1665         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
1666         (JSC::Wasm::AirIRGenerator::addLocal):
1667         (JSC::Wasm::AirIRGenerator::addConstant):
1668         (JSC::Wasm::AirIRGenerator::addRefFunc):
1669         (JSC::Wasm::AirIRGenerator::addTableSet):
1670         (JSC::Wasm::AirIRGenerator::setGlobal):
1671         (JSC::Wasm::AirIRGenerator::addReturn):
1672         * wasm/WasmB3IRGenerator.cpp:
1673         (JSC::Wasm::B3IRGenerator::addLocal):
1674         (JSC::Wasm::B3IRGenerator::addTableSet):
1675         (JSC::Wasm::B3IRGenerator::addRefFunc):
1676         (JSC::Wasm::B3IRGenerator::setGlobal):
1677         * wasm/WasmBBQPlan.cpp:
1678         (JSC::Wasm::BBQPlan::compileFunctions):
1679         * wasm/WasmCallingConvention.h:
1680         (JSC::Wasm::CallingConventionAir::marshallArgument const):
1681         (JSC::Wasm::CallingConventionAir::setupCall const):
1682         * wasm/WasmExceptionType.h:
1683         * wasm/WasmFormat.h:
1684         (JSC::Wasm::isValueType):
1685         (JSC::Wasm::isSubtype):
1686         * wasm/WasmFunctionParser.h:
1687         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1688         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
1689         * wasm/WasmInstance.cpp:
1690         (JSC::Wasm::Instance::Instance):
1691         (JSC::Wasm::Instance::getFunctionWrapper const):
1692         (JSC::Wasm::Instance::setFunctionWrapper):
1693         * wasm/WasmInstance.h:
1694         * wasm/WasmModuleInformation.h:
1695         (JSC::Wasm::ModuleInformation::referencedFunctions const):
1696         (JSC::Wasm::ModuleInformation::addReferencedFunction const):
1697         * wasm/WasmSectionParser.cpp:
1698         (JSC::Wasm::SectionParser::parseGlobal):
1699         (JSC::Wasm::SectionParser::parseInitExpr):
1700         * wasm/WasmValidate.cpp:
1701         (JSC::Wasm::Validate::addTableGet):
1702         (JSC::Wasm::Validate::addTableSet):
1703         (JSC::Wasm::Validate::addRefIsNull):
1704         (JSC::Wasm::Validate::addRefFunc):
1705         (JSC::Wasm::Validate::setLocal):
1706         (JSC::Wasm::Validate::addCall):
1707         (JSC::Wasm::Validate::addCallIndirect):
1708         * wasm/js/JSToWasm.cpp:
1709         (JSC::Wasm::createJSToWasmWrapper):
1710         * wasm/js/JSWebAssemblyHelpers.h:
1711         (JSC::isWebAssemblyHostFunction):
1712         * wasm/js/JSWebAssemblyInstance.cpp:
1713         (JSC::JSWebAssemblyInstance::visitChildren):
1714         * wasm/js/JSWebAssemblyRuntimeError.cpp:
1715         (JSC::createJSWebAssemblyRuntimeError):
1716         * wasm/js/JSWebAssemblyRuntimeError.h:
1717         * wasm/js/WasmToJS.cpp:
1718         (JSC::Wasm::handleBadI64Use):
1719         (JSC::Wasm::wasmToJS):
1720         (JSC::Wasm::emitWasmToJSException):
1721         * wasm/js/WasmToJS.h:
1722         * wasm/js/WebAssemblyFunction.cpp:
1723         (JSC::callWebAssemblyFunction):
1724         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1725         * wasm/js/WebAssemblyModuleRecord.cpp:
1726         (JSC::WebAssemblyModuleRecord::link):
1727         * wasm/wasm.json:
1728
1729 2019-06-16  Darin Adler  <darin@apple.com>
1730
1731         Rename AtomicString to AtomString
1732         https://bugs.webkit.org/show_bug.cgi?id=195276
1733
1734         Reviewed by Michael Catanzaro.
1735
1736         * many files: Let do-webcore-rename do the renaming.
1737
1738 2019-06-16  Yusuke Suzuki  <ysuzuki@apple.com>
1739
1740         [JSC] Grown region of WasmTable should be initialized with null
1741         https://bugs.webkit.org/show_bug.cgi?id=198903
1742
1743         Reviewed by Saam Barati.
1744
1745         Grown region of Wasmtable is now empty. We should initialize it with null.
1746         We also rename Wasm::Table::visitChildren to Wasm::Table::visitAggregate to
1747         align to the naming convention.
1748
1749         * wasm/WasmTable.cpp:
1750         (JSC::Wasm::Table::grow):
1751         (JSC::Wasm::Table::visitAggregate):
1752         (JSC::Wasm::Table::visitChildren): Deleted.
1753         * wasm/WasmTable.h:
1754         * wasm/js/JSWebAssemblyTable.cpp:
1755         (JSC::JSWebAssemblyTable::visitChildren):
1756
1757 2019-06-14  Keith Miller  <keith_miller@apple.com>
1758
1759         Restore PAC based cage.
1760         https://bugs.webkit.org/show_bug.cgi?id=198872
1761
1762         Rubber-stamped by Saam Barati.
1763
1764         * assembler/MacroAssemblerARM64.h:
1765         (JSC::MacroAssemblerARM64::bitFieldInsert64):
1766         * assembler/MacroAssemblerARM64E.h:
1767         * assembler/testmasm.cpp:
1768         (JSC::testCagePreservesPACFailureBit):
1769         (JSC::run):
1770         * dfg/DFGSpeculativeJIT.cpp:
1771         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
1772         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
1773         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
1774         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
1775         * ftl/FTLLowerDFGToB3.cpp:
1776         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
1777         (JSC::FTL::DFG::LowerDFGToB3::caged):
1778         * jit/AssemblyHelpers.h:
1779         (JSC::AssemblyHelpers::cageWithoutUntagging):
1780         (JSC::AssemblyHelpers::cageConditionally):
1781         (JSC::AssemblyHelpers::cage): Deleted.
1782         * jit/JITPropertyAccess.cpp:
1783         (JSC::JIT::emitIntTypedArrayGetByVal):
1784         (JSC::JIT::emitFloatTypedArrayGetByVal):
1785         (JSC::JIT::emitIntTypedArrayPutByVal):
1786         (JSC::JIT::emitFloatTypedArrayPutByVal):
1787         * llint/LowLevelInterpreter.asm:
1788         * llint/LowLevelInterpreter64.asm:
1789         * offlineasm/arm64.rb:
1790         * offlineasm/instructions.rb:
1791         * offlineasm/registers.rb:
1792         * wasm/WasmAirIRGenerator.cpp:
1793         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
1794         (JSC::Wasm::AirIRGenerator::addCallIndirect):
1795         * wasm/WasmB3IRGenerator.cpp:
1796         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1797         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1798         * wasm/WasmBinding.cpp:
1799         (JSC::Wasm::wasmToWasm):
1800         * wasm/js/JSToWasm.cpp:
1801         (JSC::Wasm::createJSToWasmWrapper):
1802         * wasm/js/WebAssemblyFunction.cpp:
1803         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1804
1805 2019-06-13  Yusuke Suzuki  <ysuzuki@apple.com>
1806
1807         Yarr bytecode compilation failure should be gracefully handled
1808         https://bugs.webkit.org/show_bug.cgi?id=198700
1809
1810         Reviewed by Michael Saboff.
1811
1812         Currently, we assume that Yarr bytecode compilation does not fail. But in fact it can fail.
1813         We should gracefully handle this failure as a runtime error, as we did for parse errors in [1].
1814         We also harden Yarr's consumed character calculation by using Checked.
1815
1816         [1]: https://bugs.webkit.org/show_bug.cgi?id=185755
1817
1818         * inspector/ContentSearchUtilities.cpp:
1819         (Inspector::ContentSearchUtilities::findMagicComment):
1820         * runtime/RegExp.cpp:
1821         (JSC::RegExp::byteCodeCompileIfNecessary):
1822         (JSC::RegExp::compile):
1823         (JSC::RegExp::compileMatchOnly):
1824         * runtime/RegExpInlines.h:
1825         (JSC::RegExp::matchInline):
1826         * yarr/YarrErrorCode.cpp:
1827         (JSC::Yarr::errorMessage):
1828         (JSC::Yarr::errorToThrow):
1829         * yarr/YarrErrorCode.h:
1830         * yarr/YarrInterpreter.cpp:
1831         (JSC::Yarr::ByteCompiler::ByteCompiler):
1832         (JSC::Yarr::ByteCompiler::compile):
1833         (JSC::Yarr::ByteCompiler::atomCharacterClass):
1834         (JSC::Yarr::ByteCompiler::atomBackReference):
1835         (JSC::Yarr::ByteCompiler::atomParenthesesOnceBegin):
1836         (JSC::Yarr::ByteCompiler::atomParenthesesTerminalBegin):
1837         (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternBegin):
1838         (JSC::Yarr::ByteCompiler::atomParentheticalAssertionBegin):
1839         (JSC::Yarr::ByteCompiler::popParenthesesStack):
1840         (JSC::Yarr::ByteCompiler::closeAlternative):
1841         (JSC::Yarr::ByteCompiler::closeBodyAlternative):
1842         (JSC::Yarr::ByteCompiler::alternativeBodyDisjunction):
1843         (JSC::Yarr::ByteCompiler::alternativeDisjunction):
1844         (JSC::Yarr::ByteCompiler::emitDisjunction):
1845
1846 2019-06-12  Yusuke Suzuki  <ysuzuki@apple.com>
1847
1848         [JSC] Polymorphic call stub's slow path should restore callee saves before performing tail call
1849         https://bugs.webkit.org/show_bug.cgi?id=198770
1850
1851         Reviewed by Saam Barati.
1852
1853         Polymorphic call stub is a bit specially patched in JS call site. Typical JS call site for tail calls
1854         are the following.
1855
1856             if (callee == patchableCallee) {
1857                 restore callee saves for tail call
1858                 prepare for tail call
1859                 jump to the target function
1860             }
1861             restore callee saves for slow path
1862             call the slow path function
1863
1864         And linking patches patchableCallee, target function, and slow path function. But polymorphic call stub
1865         patches the above `if` statement with the jump to the stub.
1866
1867             jump to the polymorphic call stub
1868
1869         This is because polymorphic call stub wants to use CallFrameShuffler to get scratch registers. As a result,
1870         "restore callee saves for tail call" thing needs to be done in the polymorphic call stubs. While it is
1871         correctly done for the major cases, we have `slowPath` skips, and that path missed restoring callee saves.
1872         This skip happens if the callee is non JSCell or non JS function, so typically, InternalFunction is handled
1873         in that path.
1874
1875         This patch does that skips after restoring callee saves.
1876
1877         * bytecode/CallLinkInfo.cpp:
1878         (JSC::CallLinkInfo::CallLinkInfo):
1879         * bytecode/CallLinkInfo.h:
1880         (JSC::CallLinkInfo::setUpCall):
1881         (JSC::CallLinkInfo::calleeGPR):
1882         (JSC::CallLinkInfo::setCalleeGPR): Deleted.
1883         * jit/Repatch.cpp:
1884         (JSC::revertCall):
1885         (JSC::linkVirtualFor):
1886         (JSC::linkPolymorphicCall):
1887         * jit/Repatch.h:
1888         * jit/ThunkGenerators.cpp:
1889         (JSC::virtualThunkFor):
1890
1891 2019-06-12  Commit Queue  <commit-queue@webkit.org>
1892
1893         Unreviewed, rolling out r246322.
1894         https://bugs.webkit.org/show_bug.cgi?id=198796
1895
1896         "It's a huge page load regression on iOS" (Requested by
1897         saamyjoon on #webkit).
1898
1899         Reverted changeset:
1900
1901         "Roll out PAC cage"
1902         https://bugs.webkit.org/show_bug.cgi?id=198726
1903         https://trac.webkit.org/changeset/246322
1904
1905 2019-06-11  Alexey Shvayka  <shvaikalesh@gmail.com>
1906
1907         JSC should throw if proxy set returns falsish in strict mode context
1908         https://bugs.webkit.org/show_bug.cgi?id=177398
1909
1910         Reviewed by Yusuke Suzuki.
1911
1912         Throw TypeError exception if Proxy's `set` trap returns falsy value.
1913         (step 6.c of https://tc39.es/ecma262/#sec-putvalue)
1914
1915         * runtime/ProxyObject.cpp:
1916         (JSC::ProxyObject::performPut):
1917         (JSC::ProxyObject::put):
1918         (JSC::ProxyObject::putByIndexCommon):
1919         * runtime/ProxyObject.h:
1920
1921 2019-06-11  Alexey Shvayka  <shvaikalesh@gmail.com>
1922
1923         Error message for non-callable Proxy `construct` trap is misleading
1924         https://bugs.webkit.org/show_bug.cgi?id=198637
1925
1926         Reviewed by Saam Barati.
1927
1928         Just like other traps, Proxy `construct` trap is invoked with [[Call]], not [[Construct]].
1929
1930         * runtime/ProxyObject.cpp:
1931         (JSC::performProxyConstruct): Tweak error message.
1932
1933 2019-06-10  Tadeu Zagallo  <tzagallo@apple.com>
1934
1935         AI BitURShift's result should not be unsigned
1936         https://bugs.webkit.org/show_bug.cgi?id=198689
1937         <rdar://problem/51550063>
1938
1939         Reviewed by Saam Barati.
1940
1941         Treating BitURShift's result as unsigned in the abstract interpreter incorrectly overflows it.
1942         This breaks the DFG and FTL, since they assume that BitURShift's result is an int32 value, but
1943         get a double constant from AI. Since the result will be converted to unsigned by UInt32ToNumber,
1944         all we have to do is store the result as a signed int32.
1945
1946         * dfg/DFGAbstractInterpreterInlines.h:
1947
1948 2019-06-11  Michael Catanzaro  <mcatanzaro@igalia.com>
1949
1950         Unreviewed build warning fixes
1951
1952         Silence -Wreturn-type warning
1953
1954         * wasm/WasmTable.cpp:
1955         (JSC::Wasm::Table::tryCreate):
1956
1957 2019-06-11  Saam Barati  <sbarati@apple.com>
1958
1959         Roll out PAC cage
1960         https://bugs.webkit.org/show_bug.cgi?id=198726
1961
1962         Reviewed by Keith Miller.
1963
1964         This patch rolls out: r245064, r245145, r245168, r245313, r245432, r245622.
1965         
1966         The resulting state we're in is we have Gigacage enabled on arm64.
1967         There is no more PAC caging.
1968
1969         We're doing this because there are performance issues with PAC caging
1970         that we haven't resolved yet.
1971
1972         * assembler/CPU.h:
1973         (JSC::isARM64E): Deleted.
1974         * assembler/MacroAssemblerARM64E.h:
1975         (JSC::MacroAssemblerARM64E::tagArrayPtr): Deleted.
1976         (JSC::MacroAssemblerARM64E::untagArrayPtr): Deleted.
1977         (JSC::MacroAssemblerARM64E::removeArrayPtrTag): Deleted.
1978         * b3/B3LowerToAir.cpp:
1979         * b3/B3PatchpointSpecial.cpp:
1980         (JSC::B3::PatchpointSpecial::admitsStack):
1981         * b3/B3StackmapSpecial.cpp:
1982         (JSC::B3::StackmapSpecial::forEachArgImpl):
1983         (JSC::B3::StackmapSpecial::isArgValidForRep):
1984         * b3/B3Validate.cpp:
1985         * b3/B3ValueRep.cpp:
1986         (JSC::B3::ValueRep::addUsedRegistersTo const):
1987         (JSC::B3::ValueRep::dump const):
1988         (WTF::printInternal):
1989         * b3/B3ValueRep.h:
1990         (JSC::B3::ValueRep::ValueRep):
1991         (JSC::B3::ValueRep::isReg const):
1992         * dfg/DFGOperations.cpp:
1993         (JSC::DFG::newTypedArrayWithSize):
1994         * dfg/DFGSpeculativeJIT.cpp:
1995         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
1996         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
1997         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
1998         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
1999         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
2000         * dfg/DFGSpeculativeJIT.h:
2001         * dfg/DFGSpeculativeJIT64.cpp:
2002         (JSC::DFG::SpeculativeJIT::compile):
2003         * ftl/FTLLowerDFGToB3.cpp:
2004         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
2005         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
2006         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2007         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet):
2008         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet):
2009         (JSC::FTL::DFG::LowerDFGToB3::caged):
2010         (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
2011         (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr): Deleted.
2012         (JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag): Deleted.
2013         * heap/ConservativeRoots.cpp:
2014         (JSC::ConservativeRoots::genericAddPointer):
2015         * jit/AssemblyHelpers.h:
2016         (JSC::AssemblyHelpers::cageConditionally):
2017         * jit/IntrinsicEmitter.cpp:
2018         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
2019         * jit/JITPropertyAccess.cpp:
2020         (JSC::JIT::emitDirectArgumentsGetByVal):
2021         (JSC::JIT::emitIntTypedArrayGetByVal):
2022         (JSC::JIT::emitFloatTypedArrayGetByVal):
2023         (JSC::JIT::emitIntTypedArrayPutByVal):
2024         (JSC::JIT::emitFloatTypedArrayPutByVal):
2025         * jit/PolymorphicCallStubRoutine.cpp:
2026         (JSC::PolymorphicCallNode::clearCallLinkInfo):
2027         * jit/RegisterSet.h:
2028         * llint/LowLevelInterpreter64.asm:
2029         * runtime/ArrayBuffer.cpp:
2030         (JSC::SharedArrayBufferContents::SharedArrayBufferContents):
2031         (JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
2032         (JSC::ArrayBufferContents::ArrayBufferContents):
2033         (JSC::ArrayBufferContents::destroy):
2034         (JSC::ArrayBufferContents::tryAllocate):
2035         (JSC::ArrayBufferContents::makeShared):
2036         (JSC::ArrayBufferContents::copyTo):
2037         * runtime/ArrayBuffer.h:
2038         (JSC::SharedArrayBufferContents::data const):
2039         (JSC::ArrayBufferContents::data const):
2040         (JSC::ArrayBuffer::data):
2041         (JSC::ArrayBuffer::data const):
2042         (JSC::ArrayBuffer::byteLength const):
2043         * runtime/ArrayBufferView.cpp:
2044         (JSC::ArrayBufferView::ArrayBufferView):
2045         * runtime/ArrayBufferView.h:
2046         (JSC::ArrayBufferView::baseAddress const):
2047         (JSC::ArrayBufferView::setRangeImpl):
2048         (JSC::ArrayBufferView::getRangeImpl):
2049         (JSC::ArrayBufferView::byteLength const): Deleted.
2050         * runtime/CachedTypes.cpp:
2051         (JSC::CachedScopedArgumentsTable::encode):
2052         (JSC::CachedScopedArgumentsTable::decode const):
2053         * runtime/CagedBarrierPtr.h:
2054         (JSC::CagedBarrierPtr::CagedBarrierPtr):
2055         (JSC::CagedBarrierPtr::set):
2056         (JSC::CagedBarrierPtr::get const):
2057         (JSC::CagedBarrierPtr::getMayBeNull const):
2058         (JSC::CagedBarrierPtr::operator== const):
2059         (JSC::CagedBarrierPtr::operator!= const):
2060         (JSC::CagedBarrierPtr::operator bool const):
2061         (JSC::CagedBarrierPtr::setWithoutBarrier):
2062         (JSC::CagedBarrierPtr::operator* const):
2063         (JSC::CagedBarrierPtr::operator-> const):
2064         (JSC::CagedBarrierPtr::operator[] const):
2065         (JSC::CagedBarrierPtr::getUnsafe const): Deleted.
2066         (JSC::CagedBarrierPtr::at const): Deleted.
2067         * runtime/DataView.cpp:
2068         (JSC::DataView::DataView):
2069         * runtime/DataView.h:
2070         (JSC::DataView::get):
2071         (JSC::DataView::set):
2072         * runtime/DirectArguments.cpp:
2073         (JSC::DirectArguments::visitChildren):
2074         (JSC::DirectArguments::overrideThings):
2075         (JSC::DirectArguments::unmapArgument):
2076         * runtime/DirectArguments.h:
2077         * runtime/GenericArguments.h:
2078         * runtime/GenericArgumentsInlines.h:
2079         (JSC::GenericArguments<Type>::visitChildren):
2080         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
2081         (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
2082         (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
2083         * runtime/GenericTypedArrayView.h:
2084         * runtime/GenericTypedArrayViewInlines.h:
2085         (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
2086         * runtime/JSArrayBufferView.cpp:
2087         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
2088         (JSC::JSArrayBufferView::JSArrayBufferView):
2089         (JSC::JSArrayBufferView::finalize):
2090         (JSC::JSArrayBufferView::slowDownAndWasteMemory):
2091         * runtime/JSArrayBufferView.h:
2092         (JSC::JSArrayBufferView::ConstructionContext::vector const):
2093         (JSC::JSArrayBufferView::isNeutered):
2094         (JSC::JSArrayBufferView::vector const):
2095         (JSC::JSArrayBufferView::hasVector const): Deleted.
2096         * runtime/JSGenericTypedArrayViewInlines.h:
2097         (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
2098         (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
2099         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
2100         * runtime/Options.h:
2101         * runtime/ScopedArgumentsTable.cpp:
2102         (JSC::ScopedArgumentsTable::clone):
2103         (JSC::ScopedArgumentsTable::setLength):
2104         * runtime/ScopedArgumentsTable.h:
2105         * runtime/SymbolTable.h:
2106         * wasm/WasmAirIRGenerator.cpp:
2107         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
2108         (JSC::Wasm::AirIRGenerator::addCallIndirect):
2109         * wasm/WasmB3IRGenerator.cpp:
2110         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
2111         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2112         * wasm/WasmBBQPlan.cpp:
2113         (JSC::Wasm::BBQPlan::complete):
2114         * wasm/WasmBinding.cpp:
2115         (JSC::Wasm::wasmToWasm):
2116         * wasm/WasmInstance.h:
2117         (JSC::Wasm::Instance::cachedMemory const):
2118         (JSC::Wasm::Instance::updateCachedMemory):
2119         * wasm/WasmMemory.cpp:
2120         (JSC::Wasm::Memory::Memory):
2121         (JSC::Wasm::Memory::~Memory):
2122         (JSC::Wasm::Memory::grow):
2123         (JSC::Wasm::Memory::dump const):
2124         * wasm/WasmMemory.h:
2125         (JSC::Wasm::Memory::memory const):
2126         * wasm/js/JSToWasm.cpp:
2127         (JSC::Wasm::createJSToWasmWrapper):
2128         * wasm/js/WebAssemblyFunction.cpp:
2129         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2130
2131 2019-06-10  Basuke Suzuki  <Basuke.Suzuki@sony.com>
2132
2133         [WinCairo] Remove build warning from RemoteInspector.
2134         https://bugs.webkit.org/show_bug.cgi?id=198724
2135
2136         Reviewed by Joseph Pecoraro.
2137
2138         In `RemoteInspectorConnectionClient.h`, an interface was defined with empty implementation.
2139         This method is to be overwritten by sub classes so that parameter name is important
2140         so they are commented out rather than just removing from the definition.
2141
2142         * inspector/remote/RemoteInspector.h:
2143
2144 2019-06-10  Sam Weinig  <weinig@apple.com>
2145
2146         Remove Dashboard support
2147         https://bugs.webkit.org/show_bug.cgi?id=198615
2148
2149         Reviewed by Ryosuke Niwa.
2150
2151         * Configurations/FeatureDefines.xcconfig:
2152
2153 2019-06-10  Devin Rousso  <drousso@apple.com>
2154
2155         Web Automation: add notifications for when remote automation is enabled/disabled
2156         https://bugs.webkit.org/show_bug.cgi?id=198703
2157         <rdar://problem/50588975>
2158
2159         Reviewed by Timothy Hatcher.
2160
2161         * inspector/remote/RemoteInspectorConstants.h:
2162
2163 2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
2164
2165         Unreviewed, build fix for non-DFG configurations, part 2
2166         https://bugs.webkit.org/show_bug.cgi?id=198023
2167
2168         * bytecode/CodeBlock.cpp:
2169         (JSC::CodeBlock::finalizeUnconditionally):
2170
2171 2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
2172
2173         Unreviewed, build fix for non-DFG configurations
2174         https://bugs.webkit.org/show_bug.cgi?id=198023
2175
2176         * bytecode/CodeBlock.cpp:
2177         (JSC::CodeBlock::finalizeUnconditionally):
2178
2179 2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
2180
2181         [JSC] UnlinkedCodeBlock should be eventually jettisoned in VM mini mode
2182         https://bugs.webkit.org/show_bug.cgi?id=198023
2183
2184         Reviewed by Saam Barati.
2185
2186         While CodeBlock is periodically jettisoned, UnlinkedCodeBlock and UnlinkedFunctionExecutable can be retained almost forever in certain type of applications.
2187         When we execute a program, which has UnlinkedProgramCodeBlock retained in CodeCache. And UnlinkedProgramCodeBlock holds array of UnlinkedFunctionExecutable.
2188         And UnlinkedFunctionExecutables hold UnlinkedFunctionCodeBlocks once it is generated. So eventually, this tree gets larger and larger until we purge
2189         UnlinkedProgramCodeBlock from CodeCache. This is OK in the browser case. We navigate to various other pages, and UnlinkedProgramCodeBlocks should eventually
2190         be pruned from CodeCache with the new ones. So this tree won't be retained forever. But the behavior is different in the other applications that do not have
2191         navigations. If they only have one program which holds all, we basically retain this tree during executing this application. The same thing can happen in
2192         web applications which does not have navigation and keeps alive for a long time. Once we hit CodeCache limit by periodically executing a new script, we will
2193         hit the uppermost of memory footprint. But until that, we increase our memory footprint.
2194
2195         However, destroying these UnlinkedCodeBlocks and UnlinkedFunctionExecutables causes a tricky problem. In the browser environment, navigation can happen at any
2196         time. So even if the given UnlinkedCodeBlock seems unused in the current page, it can be used when navigating to a new page which is under the same domain.
2197         One example is initializing function in a script. It is only executed once per page. So once it is executed, it seems that this UnlinkedCodeBlock is unused.
2198         But this will be used when we navigate to a new page. Pruning code blocks based on usage could cause performance regression.
2199
2200         But if our VM is mini VM mode, the story is different. In mini VM mode, we focus on memory footprint rather than performance e.g. daemons. The daemon never
2201         reuse these CodeCache since we do not have the navigation.
2202
2203         This patch logically makes UnlinkedFunctionExecutable -> UnlinkedCodeBlock reference weak when VM is mini mode. If UnlinkedCodeBlock is used in previous GC
2204         cycle, we retain it. But if it is not used, and if UnlinkedFunctionExecutable is only the cell keeping UnlinkedCodeBlock alive, we destroy it. It is a
2205         heuristic. In a super pathological case, it could increase memory footprint. Consider the following example.
2206
2207             UnlinkedFunctionExecutable(A1) -> UnlinkedCodeBlock(B1) -> UnlinkedFunctionExecutable(C1) -> UnlinkedCodeBlock(D1)
2208                                                                                                              ^
2209                                                                                                          CodeBlock(E1)
2210
2211         We could delete A1, B1, and C1 while keeping D1. But if we eventually re-execute the same code corresponding to A1, B1, C1, they will be newly created, and
2212         we will create duplicate UnlinkedCodeBlock and instructions stream for D1.
2213
2214                                                                                                          UnlinkedCodeBlock(D1)
2215                                                                                                              ^
2216                                                                                                          CodeBlock(E1)
2217
2218             UnlinkedFunctionExecutable(A2) -> UnlinkedCodeBlock(B2) -> UnlinkedFunctionExecutable(C2) -> UnlinkedCodeBlock(D2)
2219
2220         But this does not happen in practice and even it happens, we eventually discard D1 and D2 since CodeBlock E1 will be jettisoned anyway. So in practice, we do
2221         not see memory footprint increase. We tested it in Gmail and the target application, but both said memory footprint reduction (30 MB / 400 MB and 1 MB /6 MB).
2222         While this affects on performance much on tests which has navigation (1-3 % regression in Speedometer2, note that JetStream2 does not show regression in x64,
2223         while it is not enabling mini mode), we do not apply this to non mini mode VM until we come up with a good strategy to fasten performance of re-generation.
2224         Personally I think flushing destroyed UnlinkedCodeBlock to the disk sounds promising.
2225
2226         If UnlinkedCodeBlock is generated from bytecode cache, we do not make UnlinkedFunctionExecutable -> UnlinkedCodeBlock link weak because the decoder of the bytecode
2227         cache assumes that generated JSCells won't be destroyed while the parent cells of that cell are live. This is true in the current implementation, and this assumption
2228         will be broken with this patch. So, for now, we do not make this link weak. Currently, our target application does not use bytecode cache so it is OK.
2229
2230         This patch also introduce simple heuristic. We are counting UnlinkedCodeBlock's age. And once the age becomes maximum size, we make UnlinkedFunctionExecutable ->
2231         UnlinkedCodeBlock link weak. We also use execution counter information to reset this age: CodeBlock will reset undelying UnlinkedCodeBlock's age if it has executed
2232         While this heuristic is quite simple, it has some effect in practice. Basically what happens with this heuristic is that UnlinkedFunctionExecutable ->
2233         UnlinkedCodeBlock link strong. When GC happens, we are executing some CodeBlocks, which become live. And ScriptExecutables -> UnlinkedFunctionExecutables held
2234         by this CodeBlock become also live. Then UnlinkedFunctionExecutables can mark the child UnlinkedCodeBlocks if it is not so old.
2235         If some of parent UnlinkedFunctionExecutable becomes dead, child UnlinkedCodeBlocks tends to be dead unless some live CodeBlock holds it. But it is OK for a first
2236         heuristics since this means that parent code block is now considered old, reachable UnlinkedCodeBlock will be used when the parent is executed again. So destroying
2237         the tree is OK even if the tree may include some new UnlinkedCodeBlock. While we could make more sophisticated mechanism to manage these lifetime, I think this is a
2238         good starting point.
2239
2240         Based on measurement, we pick 7 as a maximum age. If we pick 0, we can get more memory reduction (1 - 1.5 MB!), while we ends up reparsing codes so many times.
2241         It seems that 7 can reduce fair amount of memory while doing small # of reparsing on average (usually, 1, 2. Sometimes, 100. But not 300, which is the case in 0).
2242         If we want to get more memory reduction for the sake of performance, we could decrease this age limit.
2243
2244         Since we do not have an automated script right now so it is a bit difficult to measure memory footprint precisely. But manual testing shows that this patch improves
2245         memory footprint of our target application from about 6.5 MB to about 5.9 MB.
2246
2247         * bytecode/CodeBlock.cpp:
2248         (JSC::CodeBlock::finalizeUnconditionally):
2249         * bytecode/CodeBlock.h:
2250         * bytecode/UnlinkedCodeBlock.cpp:
2251         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2252         (JSC::UnlinkedCodeBlock::visitChildren):
2253         * bytecode/UnlinkedCodeBlock.h:
2254         (JSC::UnlinkedCodeBlock::age const):
2255         (JSC::UnlinkedCodeBlock::resetAge):
2256         * bytecode/UnlinkedFunctionExecutable.cpp:
2257         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2258         (JSC::UnlinkedFunctionExecutable::visitChildren):
2259         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
2260         (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
2261         (JSC::UnlinkedFunctionExecutable::finalizeUnconditionally):
2262         * bytecode/UnlinkedFunctionExecutable.h:
2263         * heap/Heap.cpp:
2264         (JSC::Heap::finalizeUnconditionalFinalizers):
2265         * runtime/CachedTypes.cpp:
2266         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2267         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2268         * runtime/CodeSpecializationKind.h:
2269         * runtime/Options.h:
2270         * runtime/VM.cpp:
2271         (JSC::VM::isInMiniMode): Deleted.
2272         * runtime/VM.h:
2273         (JSC::VM::isInMiniMode):
2274         (JSC::VM::useUnlinkedCodeBlockJettisoning):
2275
2276 2019-06-10  Timothy Hatcher  <timothy@apple.com>
2277
2278         Integrate dark mode support for iOS.
2279         https://bugs.webkit.org/show_bug.cgi?id=198687
2280         rdar://problem/51545643
2281
2282         Reviewed by Tim Horton.
2283
2284         * Configurations/FeatureDefines.xcconfig:
2285
2286 2019-06-10  Adrian Perez de Castro  <aperez@igalia.com>
2287
2288         [JSC] Linker fails when unified sources are not in use
2289         https://bugs.webkit.org/show_bug.cgi?id=198722
2290
2291         Reviewed by Keith Miller.
2292
2293         Added missing inclusions of headers in several files which make use of inline functions.
2294
2295         * b3/B3AtomicValue.cpp:
2296         * b3/B3BlockInsertionSet.cpp:
2297         * b3/B3FenceValue.cpp:
2298         * b3/B3LowerMacrosAfterOptimizations.cpp:
2299         * b3/B3PureCSE.cpp:
2300         * b3/B3StackmapValue.cpp:
2301         * b3/B3SwitchValue.cpp:
2302         * b3/B3UseCounts.cpp:
2303         * b3/B3VariableValue.cpp:
2304         * b3/B3WasmAddressValue.cpp:
2305         * b3/B3WasmBoundsCheckValue.cpp:
2306         * ftl/FTLCompile.cpp:
2307         * wasm/WasmSectionParser.cpp:
2308         * wasm/WasmTable.cpp:
2309         * wasm/WasmValidate.cpp:
2310
2311 2019-06-10  Keith Miller  <keith_miller@apple.com>
2312
2313         Make new Symbol/Promise API public
2314         https://bugs.webkit.org/show_bug.cgi?id=198709
2315
2316         Reviewed by Saam Barati.
2317
2318         We also need to #ifdef some tests when building for older
2319         platforms because the signatures for some methods are outdated on
2320         those platforms.
2321
2322         * API/JSObjectRef.h:
2323         * API/JSObjectRefPrivate.h:
2324         * API/JSValue.h:
2325         * API/JSValuePrivate.h:
2326         * API/JSValueRef.h:
2327         * API/tests/testapi.mm:
2328         (testObjectiveCAPIMain):
2329
2330 2019-06-09  Commit Queue  <commit-queue@webkit.org>
2331
2332         Unreviewed, rolling out r246150, r246160, and r246166.
2333         https://bugs.webkit.org/show_bug.cgi?id=198698
2334
2335         Regresses page loading time on iOS 13 (Requested by keith_m__
2336         on #webkit).
2337
2338         Reverted changesets:
2339
2340         "Reenable Gigacage on ARM64."
2341         https://bugs.webkit.org/show_bug.cgi?id=198453
2342         https://trac.webkit.org/changeset/246150
2343
2344         "Unrevied build fix for FTL without Gigacage."
2345         https://trac.webkit.org/changeset/246160
2346
2347         "Fix typo in cageWithoutUntagging"
2348         https://bugs.webkit.org/show_bug.cgi?id=198617
2349         https://trac.webkit.org/changeset/246166
2350
2351 2019-06-09  Yusuke Suzuki  <ysuzuki@apple.com>
2352
2353         [JSC] Use mergePrediction in ValuePow prediction propagation
2354         https://bugs.webkit.org/show_bug.cgi?id=198648
2355
2356         Reviewed by Saam Barati.
2357
2358         We are accidentally using setPrediction. This is wrong since prediction propagation (not processInvariant)
2359         must extend the speculation types to ensure we eventually reach to the fixed point. setPrediction can discard
2360         previously configured predictions, can lead to oscillation potentially. Use mergePrediction instead.
2361
2362         * dfg/DFGPredictionPropagationPhase.cpp:
2363
2364 2019-06-07  Tadeu Zagallo  <tzagallo@apple.com>
2365
2366         AI should get GetterSetter structure from the base's GlobalObject for GetGetterSetterByOffset
2367         https://bugs.webkit.org/show_bug.cgi?id=198581
2368         <rdar://problem/51099753>
2369
2370         Reviewed by Saam Barati.
2371
2372         For GetGetterSetterByOffset, when the abstract interpreter fails to read the property
2373         from the object, it gets the GetterSetter structure from the CodeBlock's global object.
2374         However, that's not correct, since the global object for the base object might differ
2375         from the CodeBlock's. Instead, we try to get the global object from the base, when it's
2376         a constant object. Otherwise, we can't infer the value and only set the type.
2377
2378         * dfg/DFGAbstractInterpreterInlines.h:
2379         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2380
2381 2019-06-06  Devin Rousso  <drousso@apple.com>
2382
2383         Web Inspector: create CommandLineAPIHost lazily like the other agents
2384         https://bugs.webkit.org/show_bug.cgi?id=196047
2385         <rdar://problem/49087835>
2386
2387         Reviewed by Timothy Hatcher.
2388
2389         * inspector/InjectedScriptManager.h:
2390         * inspector/InjectedScriptManager.cpp:
2391         (Inspector::InjectedScriptManager::connect): Added.
2392
2393 2019-06-06  Keith Miller  <keith_miller@apple.com>
2394
2395         Fix typo in cageWithoutUntagging
2396         https://bugs.webkit.org/show_bug.cgi?id=198617
2397
2398         Reviewed by Saam Barati.
2399
2400         * assembler/testmasm.cpp:
2401         (JSC::testCagePreservesPACFailureBit):
2402         * dfg/DFGSpeculativeJIT.cpp:
2403         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
2404         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
2405         * jit/AssemblyHelpers.h:
2406         (JSC::AssemblyHelpers::cageWithoutUntagging):
2407         (JSC::AssemblyHelpers::cageConditionally):
2408         (JSC::AssemblyHelpers::cageWithoutUntaging): Deleted.
2409
2410 2019-06-06  Alexey Shvayka  <shvaikalesh@gmail.com>
2411
2412         JSON.parse throws incorrect exception when called w/o arguments
2413         https://bugs.webkit.org/show_bug.cgi?id=198574
2414
2415         Reviewed by Yusuke Suzuki.
2416
2417         Always coerce first argument to string and attempt to parse it.
2418         (steps 1-2 of https://tc39.github.io/ecma262/#sec-json.parse)
2419
2420         * runtime/JSONObject.cpp:
2421         (JSC::JSONProtoFuncParse): Remove argumentCount check.
2422
2423 2019-06-06  Keith Miller  <keith_miller@apple.com>
2424
2425         Unrevied build fix for FTL without Gigacage.
2426
2427         * ftl/FTLLowerDFGToB3.cpp:
2428         (JSC::FTL::DFG::LowerDFGToB3::caged):
2429
2430 2019-06-06  Michael Catanzaro  <mcatanzaro@igalia.com>
2431
2432         aarch64: ‘JSC::ARM64Assembler::LinkRecord::<unnamed union>::RealTypes::m_compareRegister’ is too small to hold all values of ‘JSC::ARM64Assembler::RegisterID’ {aka ‘enum JSC::ARM64Registers::RegisterID’}
2433         https://bugs.webkit.org/show_bug.cgi?id=198014
2434
2435         Reviewed by Yusuke Suzuki.
2436
2437         When building for aarch64, there is a huge warning spam here. It's impossible to see any
2438         other warnings. This has been ongoing for so long I've begun to suspect that nobody works
2439         on this architecture.
2440
2441         Anyway, the problem is because we need eight bits to store all possible RegisterID values,
2442         but the bitfield is only six bits wide. Fix it. The COMPILE_ASSERT checking the size of this
2443         struct is still happy, so I presume the change is OK.
2444
2445         * assembler/ARM64Assembler.h:
2446
2447 2019-06-06  Keith Miller  <keith_miller@apple.com>
2448
2449         Reenable Gigacage on ARM64.
2450         https://bugs.webkit.org/show_bug.cgi?id=198453
2451
2452         Reviewed by Michael Saboff.
2453
2454         This patch adds back Gigacaging on Apple's ARM64 ports. Unlike the
2455         old Gigacage however, arm64e uses both Gigacaging and PAC. In
2456         order to ensure the PAC bits are not stripped in the caging
2457         process we use the bit field insert instruction to take the low
2458         bits from caging and the high bits from the PAC authentication.
2459
2460         * assembler/MacroAssemblerARM64.h:
2461         (JSC::MacroAssemblerARM64::bitFieldInsert64):
2462         * assembler/MacroAssemblerARM64E.h:
2463         * assembler/testmasm.cpp:
2464         (JSC::testCagePreservesPACFailureBit):
2465         (JSC::run):
2466         * dfg/DFGSpeculativeJIT.cpp:
2467         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
2468         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
2469         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
2470         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
2471         * ftl/FTLLowerDFGToB3.cpp:
2472         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2473         (JSC::FTL::DFG::LowerDFGToB3::caged):
2474         * jit/AssemblyHelpers.h:
2475         (JSC::AssemblyHelpers::cageWithoutUntaging):
2476         (JSC::AssemblyHelpers::cageConditionally):
2477         (JSC::AssemblyHelpers::cage): Deleted.
2478         * jit/JITPropertyAccess.cpp:
2479         (JSC::JIT::emitIntTypedArrayGetByVal):
2480         (JSC::JIT::emitFloatTypedArrayGetByVal):
2481         (JSC::JIT::emitIntTypedArrayPutByVal):
2482         (JSC::JIT::emitFloatTypedArrayPutByVal):
2483         * llint/LowLevelInterpreter.asm:
2484         * llint/LowLevelInterpreter64.asm:
2485         * offlineasm/arm64.rb:
2486         * offlineasm/instructions.rb:
2487         * offlineasm/registers.rb:
2488         * wasm/WasmAirIRGenerator.cpp:
2489         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
2490         (JSC::Wasm::AirIRGenerator::addCallIndirect):
2491         * wasm/WasmB3IRGenerator.cpp:
2492         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
2493         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2494         * wasm/WasmBinding.cpp:
2495         (JSC::Wasm::wasmToWasm):
2496         * wasm/js/JSToWasm.cpp:
2497         (JSC::Wasm::createJSToWasmWrapper):
2498         * wasm/js/WebAssemblyFunction.cpp:
2499         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2500
2501 2019-06-06  Michael Saboff  <msaboff@apple.com>
2502
2503         [ARM64E]: Add disassembler support for authenticated instructions
2504         https://bugs.webkit.org/show_bug.cgi?id=198562
2505
2506         Reviewed by Keith Miller.
2507
2508         Added support for all the instructions supported in ARM64EAssembler.h.
2509
2510         * disassembler/ARM64/A64DOpcode.cpp:
2511         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::format):
2512         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::format):
2513         (JSC::ARM64Disassembler::A64DOpcodeHint::format):
2514         (JSC::ARM64Disassembler::A64DOpcodeHint::opName):
2515         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::format):
2516         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpName):
2517         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::format):
2518         * disassembler/ARM64/A64DOpcode.h:
2519         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::opNameIndex):
2520         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opName):
2521         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opNum):
2522         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::mBit):
2523         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::sBit):
2524         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::wBit):
2525         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::immediate10):
2526         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpCode):
2527         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op2):
2528         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op3):
2529         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op4):
2530         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::mBit):
2531         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::rm):
2532         (JSC::ARM64Disassembler::A64DOpcodeHint::opName): Deleted.
2533
2534 2019-06-05  Justin Michaud  <justin_michaud@apple.com>
2535
2536         [WASM-References] Add support for Anyref tables, Table.get and Table.set (for Anyref only).
2537         https://bugs.webkit.org/show_bug.cgi?id=198398
2538
2539         Reviewed by Saam Barati.
2540
2541         Create a new table subtype called FuncRefTable (note: Anyfunc was renamed to Funcref in the references spec).
2542         Table now write-barriers and visits its children's wrapper objects. FuncRefTable caches some extra data to
2543         support calling from wasm. A JSWebAssemblyTable is required to set an anyref element, but this is only because
2544         we need to write barrier it (so it should not restrict how we implement threads). This patch does, however,
2545         restrict the implementation of function references to require every Ref.func to have an associated wrapper. This
2546         can be done statically, so this too should not restrict our threads implementation. 
2547
2548         * wasm/WasmAirIRGenerator.cpp:
2549         (JSC::Wasm::AirIRGenerator::addTableGet):
2550         (JSC::Wasm::AirIRGenerator::addTableSet):
2551         (JSC::Wasm::AirIRGenerator::addCallIndirect):
2552         * wasm/WasmB3IRGenerator.cpp:
2553         (JSC::Wasm::B3IRGenerator::addLocal):
2554         (JSC::Wasm::B3IRGenerator::addTableGet):
2555         (JSC::Wasm::B3IRGenerator::addTableSet):
2556         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2557         * wasm/WasmFormat.h:
2558         (JSC::Wasm::TableInformation::TableInformation):
2559         (JSC::Wasm::TableInformation::type const):
2560         * wasm/WasmFunctionParser.h:
2561         (JSC::Wasm::FunctionParser<Context>::parseExpression):
2562         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
2563         * wasm/WasmSectionParser.cpp:
2564         (JSC::Wasm::SectionParser::parseTableHelper):
2565         * wasm/WasmTable.cpp:
2566         (JSC::Wasm::Table::Table):
2567         (JSC::Wasm::Table::tryCreate):
2568         (JSC::Wasm::Table::grow):
2569         (JSC::Wasm::Table::clear):
2570         (JSC::Wasm::Table::set):
2571         (JSC::Wasm::Table::get):
2572         (JSC::Wasm::Table::visitChildren):
2573         (JSC::Wasm::FuncRefTable::FuncRefTable):
2574         (JSC::Wasm::FuncRefTable::setFunction):
2575         (JSC::Wasm::Table::~Table): Deleted.
2576         (JSC::Wasm::Table::clearFunction): Deleted.
2577         (JSC::Wasm::Table::setFunction): Deleted.
2578         * wasm/WasmTable.h:
2579         (JSC::Wasm::Table::length const):
2580         (JSC::Wasm::Table::type const):
2581         (JSC::Wasm::Table::setOwner):
2582         (JSC::Wasm::FuncRefTable::offsetOfFunctions):
2583         (JSC::Wasm::FuncRefTable::offsetOfInstances):
2584         (JSC::Wasm::Table::offsetOfFunctions): Deleted.
2585         (JSC::Wasm::Table::offsetOfInstances): Deleted.
2586         * wasm/WasmValidate.cpp:
2587         (JSC::Wasm::Validate::addTableGet):
2588         (JSC::Wasm::Validate::addTableSet):
2589         (JSC::Wasm::Validate::addCallIndirect):
2590         * wasm/js/JSWebAssemblyTable.cpp:
2591         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
2592         (JSC::JSWebAssemblyTable::finishCreation):
2593         (JSC::JSWebAssemblyTable::visitChildren):
2594         (JSC::JSWebAssemblyTable::grow):
2595         (JSC::JSWebAssemblyTable::get):
2596         (JSC::JSWebAssemblyTable::set):
2597         (JSC::JSWebAssemblyTable::clear):
2598         (JSC::JSWebAssemblyTable::getFunction): Deleted.
2599         (JSC::JSWebAssemblyTable::clearFunction): Deleted.
2600         (JSC::JSWebAssemblyTable::setFunction): Deleted.
2601         * wasm/js/JSWebAssemblyTable.h:
2602         * wasm/js/WebAssemblyModuleRecord.cpp:
2603         (JSC::WebAssemblyModuleRecord::link):
2604         (JSC::WebAssemblyModuleRecord::evaluate):
2605         * wasm/js/WebAssemblyTableConstructor.cpp:
2606         (JSC::constructJSWebAssemblyTable):
2607         * wasm/js/WebAssemblyTablePrototype.cpp:
2608         (JSC::webAssemblyTableProtoFuncGet):
2609         (JSC::webAssemblyTableProtoFuncSet):
2610         * wasm/wasm.json:
2611
2612 2019-06-05  Justin Michaud  <justin_michaud@apple.com>
2613
2614         WebAssembly: pow functions returns 0 when exponent 1.0 or -1.0
2615         https://bugs.webkit.org/show_bug.cgi?id=198106
2616
2617         Reviewed by Saam Barati.
2618
2619         Fix bug caused by using fcsel sX instead of fcsel dX on an f64 value in moveDoubleConditionally32.
2620
2621         * assembler/MacroAssemblerARM64.h:
2622         (JSC::MacroAssemblerARM64::moveDoubleConditionally32):
2623
2624 2019-06-05  Alex Christensen  <achristensen@webkit.org>
2625
2626         Progress towards resurrecting Mac CMake build
2627         https://bugs.webkit.org/show_bug.cgi?id=197132
2628
2629         Reviewed by Don Olmstead.
2630
2631         * API/JSScript.mm:
2632         (-[JSScript readCache]):
2633         (-[JSScript sourceCode]):
2634         (-[JSScript jsSourceCode]):
2635         (-[JSScript writeCache:]):
2636         * CMakeLists.txt:
2637
2638 == Rolled over to ChangeLog-2019-06-05 ==