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