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