All prototypes should call didBecomePrototype()
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-05-07  Robin Morisset  <rmorisset@apple.com>
2
3         All prototypes should call didBecomePrototype()
4         https://bugs.webkit.org/show_bug.cgi?id=196315
5
6         Reviewed by Saam Barati.
7
8         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
9
10         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
11         create structures with invalid prototypes.
12         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
13         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
14
15         * runtime/BigIntPrototype.cpp:
16         (JSC::BigIntPrototype::finishCreation):
17         * runtime/BooleanPrototype.cpp:
18         (JSC::BooleanPrototype::finishCreation):
19         * runtime/DatePrototype.cpp:
20         (JSC::DatePrototype::finishCreation):
21         * runtime/ErrorConstructor.cpp:
22         (JSC::ErrorConstructor::finishCreation):
23         * runtime/ErrorPrototype.cpp:
24         (JSC::ErrorPrototype::finishCreation):
25         * runtime/FunctionConstructor.cpp:
26         (JSC::FunctionConstructor::finishCreation):
27         * runtime/FunctionPrototype.cpp:
28         (JSC::FunctionPrototype::finishCreation):
29         * runtime/IntlCollatorPrototype.cpp:
30         (JSC::IntlCollatorPrototype::finishCreation):
31         * runtime/IntlDateTimeFormatPrototype.cpp:
32         (JSC::IntlDateTimeFormatPrototype::finishCreation):
33         * runtime/IntlNumberFormatPrototype.cpp:
34         (JSC::IntlNumberFormatPrototype::finishCreation):
35         * runtime/IntlPluralRulesPrototype.cpp:
36         (JSC::IntlPluralRulesPrototype::finishCreation):
37         * runtime/JSArrayBufferPrototype.cpp:
38         (JSC::JSArrayBufferPrototype::finishCreation):
39         * runtime/JSDataViewPrototype.cpp:
40         (JSC::JSDataViewPrototype::finishCreation):
41         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
42         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
43         * runtime/JSGlobalObject.cpp:
44         (JSC::createConsoleProperty):
45         * runtime/JSPromisePrototype.cpp:
46         (JSC::JSPromisePrototype::finishCreation):
47         * runtime/JSTypedArrayViewConstructor.cpp:
48         (JSC::JSTypedArrayViewConstructor::finishCreation):
49         * runtime/JSTypedArrayViewPrototype.cpp:
50         (JSC::JSTypedArrayViewPrototype::finishCreation):
51         * runtime/NumberPrototype.cpp:
52         (JSC::NumberPrototype::finishCreation):
53         * runtime/RegExpPrototype.cpp:
54         (JSC::RegExpPrototype::finishCreation):
55         * runtime/StringPrototype.cpp:
56         (JSC::StringPrototype::finishCreation):
57         * runtime/Structure.cpp:
58         (JSC::Structure::isValidPrototype):
59         (JSC::Structure::changePrototypeTransition):
60         * runtime/Structure.h:
61         * runtime/SymbolPrototype.cpp:
62         (JSC::SymbolPrototype::finishCreation):
63         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
64         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
65         * wasm/js/WebAssemblyInstancePrototype.cpp:
66         (JSC::WebAssemblyInstancePrototype::finishCreation):
67         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
68         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
69         * wasm/js/WebAssemblyMemoryPrototype.cpp:
70         (JSC::WebAssemblyMemoryPrototype::finishCreation):
71         * wasm/js/WebAssemblyModulePrototype.cpp:
72         (JSC::WebAssemblyModulePrototype::finishCreation):
73         * wasm/js/WebAssemblyPrototype.cpp:
74         (JSC::WebAssemblyPrototype::finishCreation):
75         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
76         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
77         * wasm/js/WebAssemblyTablePrototype.cpp:
78         (JSC::WebAssemblyTablePrototype::finishCreation):
79
80 2019-05-07  Robin Morisset  <rmorisset@apple.com>
81
82         WTF::BitVector should have an isEmpty() method
83         https://bugs.webkit.org/show_bug.cgi?id=197637
84
85         Reviewed by Keith Miller.
86
87         Just replaces some comparison of bitCount() to 0 by calls to isEmpty()
88
89         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
90
91 2019-05-07  Commit Queue  <commit-queue@webkit.org>
92
93         Unreviewed, rolling out r244978.
94         https://bugs.webkit.org/show_bug.cgi?id=197671
95
96         TemplateObject map should use start/end offsets (Requested by
97         yusukesuzuki on #webkit).
98
99         Reverted changeset:
100
101         "TemplateObject passed to template literal tags are not always
102         identical for the same source location."
103         https://bugs.webkit.org/show_bug.cgi?id=190756
104         https://trac.webkit.org/changeset/244978
105
106 2019-05-07  Tadeu Zagallo  <tzagallo@apple.com>
107
108         tryCachePutByID should not crash if target offset changes
109         https://bugs.webkit.org/show_bug.cgi?id=197311
110         <rdar://problem/48033612>
111
112         Reviewed by Filip Pizlo.
113
114         When tryCachePutID is called with a cacheable setter, if the target object where the setter was
115         found is still in the prototype chain and there's no poly protos in the chain, we use
116         generateConditionsForPrototypePropertyHit to validate that the target object remains the same.
117         It checks for the absence of the property in every object in the prototype chain from the base
118         down to the target object and checks that the property is still present in the target object. It
119         also bails if there are any uncacheable objects, proxies or dictionary objects in the prototype
120         chain. However, it does not consider two edge cases:
121         - It asserts that the property should still be at the same offset in the target object, but this
122         assertion does not hold if the setter deletes properties of the object and causes the structure
123         to be flattened after the deletion. Instead of asserting, we just use the updated offset.
124         - It does not check whether the new slot is also a setter, which leads to a crash in case it's not.
125
126         * jit/Repatch.cpp:
127         (JSC::tryCachePutByID):
128
129 2019-05-07  Saam Barati  <sbarati@apple.com>
130
131         Don't OSR enter into an FTL CodeBlock that has been jettisoned
132         https://bugs.webkit.org/show_bug.cgi?id=197531
133         <rdar://problem/50162379>
134
135         Reviewed by Yusuke Suzuki.
136
137         Sometimes we make silly mistakes. This is one of those times. It's invalid to OSR
138         enter into an FTL OSR entry code block that has been jettisoned already.
139
140         * dfg/DFGJITCode.cpp:
141         (JSC::DFG::JITCode::clearOSREntryBlockAndResetThresholds):
142         * dfg/DFGJITCode.h:
143         (JSC::DFG::JITCode::clearOSREntryBlock): Deleted.
144         * dfg/DFGOSREntry.cpp:
145         (JSC::DFG::prepareOSREntry):
146         (JSC::DFG::prepareCatchOSREntry):
147         * dfg/DFGOperations.cpp:
148         * ftl/FTLOSREntry.cpp:
149         (JSC::FTL::prepareOSREntry):
150
151 2019-05-06  Keith Miller  <keith_miller@apple.com>
152
153         JSWrapperMap should check if existing prototype properties are wrappers when copying exported methods.
154         https://bugs.webkit.org/show_bug.cgi?id=197324
155         <rdar://problem/50253144>
156
157         Reviewed by Saam Barati.
158
159         The current implementation prevents using JSExport to shadow a
160         method from a super class. This was because we would only add a
161         method if the prototype didn't already claim to have the
162         property. Normally this would only happen if an Objective-C super
163         class already exported a ObjCCallbackFunction for the method,
164         however, if the user exports a property that is already on
165         Object.prototype the overriden method won't be exported.
166
167         This patch fixes the object prototype issue by checking if the
168         property on the prototype chain is an ObjCCallbackFunction, if
169         it's not then it adds an override.
170
171         * API/JSWrapperMap.mm:
172         (copyMethodsToObject):
173         * API/tests/testapi.mm:
174         (-[ToStringClass toString]):
175         (-[ToStringClass other]):
176         (-[ToStringSubclass toString]):
177         (-[ToStringSubclassNoProtocol toString]):
178         (testToString):
179         (testObjectiveCAPI):
180
181 2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>
182
183         [JSC] We should check OOM for description string of Symbol
184         https://bugs.webkit.org/show_bug.cgi?id=197634
185
186         Reviewed by Keith Miller.
187
188         When resoling JSString for description of Symbol, we should check OOM error.
189         We also change JSValueMakeSymbol(..., nullptr) to returning a symbol value
190         without description, (1) to simplify the code and (2) give a way for JSC API
191         to create a symbol value without description.
192
193         * API/JSValueRef.cpp:
194         (JSValueMakeSymbol):
195         * API/tests/testapi.cpp:
196         (TestAPI::symbolsTypeof):
197         (TestAPI::symbolsDescription):
198         (testCAPIViaCpp):
199         * dfg/DFGOperations.cpp:
200         * runtime/Symbol.cpp:
201         (JSC::Symbol::createWithDescription):
202         * runtime/Symbol.h:
203         * runtime/SymbolConstructor.cpp:
204         (JSC::callSymbol):
205
206 2019-05-06  Keith Rollin  <krollin@apple.com>
207
208         Temporarily disable generate-xcfilelists
209         https://bugs.webkit.org/show_bug.cgi?id=197619
210         <rdar://problem/50507392>
211
212         Reviewed by Alex Christensen.
213
214         We need to perform a significant update to the generate-xcfilelist
215         scripts. This work involves coordinated work with another facility. If
216         the work does not occur in tandem, the build will be broken. To avoid
217         this, disable the invoking of the scripts during the transition. The
218         checking will be restored once the new scripts are in place.
219
220         * Scripts/check-xcfilelists.sh:
221
222 2019-05-06  Basuke Suzuki  <Basuke.Suzuki@sony.com>
223
224         [PlayStation] Fix build break since r244919
225         https://bugs.webkit.org/show_bug.cgi?id=197627
226
227         Reviewed by Ross Kirsling.
228
229         Bugfix for POSIX socket implementation and suppress warnings.
230
231         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
232         (Inspector::RemoteInspectorConnectionClient::didAccept):
233         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
234         (Inspector::Socket::getPort):
235
236 2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>
237
238         TemplateObject passed to template literal tags are not always identical for the same source location.
239         https://bugs.webkit.org/show_bug.cgi?id=190756
240
241         Reviewed by Saam Barati.
242
243         Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
244         when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
245
246         1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
247         2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
248
249         In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
250         ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
251         But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
252         which maps source locations to cached site objects.
253
254         1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
255         2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
256         3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
257
258         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
259         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
260         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
261         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
262         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
263         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
264         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
265         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
266         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
267         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
268         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
269         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
270         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
271         * Scripts/wkbuiltins/builtins_templates.py:
272         * bytecode/CodeBlock.cpp:
273         (JSC::CodeBlock::finishCreation):
274         (JSC::CodeBlock::setConstantRegisters):
275         * bytecode/CodeBlock.h:
276         * bytecode/UnlinkedFunctionExecutable.cpp:
277         (JSC::UnlinkedFunctionExecutable::link):
278         * bytecode/UnlinkedFunctionExecutable.h:
279         * bytecompiler/BytecodeGenerator.cpp:
280         (JSC::BytecodeGenerator::addTemplateObjectConstant):
281         (JSC::BytecodeGenerator::emitGetTemplateObject):
282         * bytecompiler/BytecodeGenerator.h:
283         * runtime/CachedTypes.cpp:
284         (JSC::CachedTemplateObjectDescriptor::encode):
285         (JSC::CachedTemplateObjectDescriptor::decode const):
286         (JSC::CachedJSValue::encode):
287         (JSC::CachedJSValue::decode const):
288         * runtime/EvalExecutable.cpp:
289         (JSC::EvalExecutable::ensureTemplateObjectMap):
290         (JSC::EvalExecutable::visitChildren):
291         * runtime/EvalExecutable.h:
292         * runtime/FunctionExecutable.cpp:
293         (JSC::FunctionExecutable::finishCreation):
294         (JSC::FunctionExecutable::visitChildren):
295         (JSC::FunctionExecutable::fromGlobalCode):
296         (JSC::FunctionExecutable::ensureRareDataSlow):
297         (JSC::FunctionExecutable::ensureTemplateObjectMap):
298         * runtime/FunctionExecutable.h:
299         * runtime/JSModuleRecord.cpp:
300         (JSC::JSModuleRecord::instantiateDeclarations):
301         * runtime/JSTemplateObjectDescriptor.cpp:
302         (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
303         (JSC::JSTemplateObjectDescriptor::create):
304         * runtime/JSTemplateObjectDescriptor.h:
305         * runtime/ModuleProgramExecutable.cpp:
306         (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
307         (JSC::ModuleProgramExecutable::visitChildren):
308         * runtime/ModuleProgramExecutable.h:
309         * runtime/ProgramExecutable.cpp:
310         (JSC::ProgramExecutable::ensureTemplateObjectMap):
311         (JSC::ProgramExecutable::visitChildren):
312         * runtime/ProgramExecutable.h:
313         * runtime/ScriptExecutable.cpp:
314         (JSC::ScriptExecutable::topLevelExecutable):
315         (JSC::ScriptExecutable::createTemplateObject):
316         (JSC::ScriptExecutable::ensureTemplateObjectMap):
317         * runtime/ScriptExecutable.h:
318         * tools/JSDollarVM.cpp:
319         (JSC::functionCreateBuiltin):
320         (JSC::functionDeleteAllCodeWhenIdle):
321         (JSC::JSDollarVM::finishCreation):
322
323 2019-05-04  Tadeu Zagallo  <tzagallo@apple.com>
324
325         TypedArrays should not store properties that are canonical numeric indices
326         https://bugs.webkit.org/show_bug.cgi?id=197228
327         <rdar://problem/49557381>
328
329         Reviewed by Saam Barati.
330
331         According to the spec[1]:
332         - TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty if the index is a
333         CanonicalNumericIndexString, but invalid according to IntegerIndexedElementGet and similar
334         functions. I.e., there are a few properties that should not be set in a TypedArray, like NaN,
335         Infinity and -0.
336         - On DefineOwnProperty, the out-of-bounds check should be performed before validating the property
337         descriptor.
338         - On GetOwnProperty, the returned descriptor for numeric properties should have writable set to true.
339
340         [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
341
342         * CMakeLists.txt:
343         * JavaScriptCore.xcodeproj/project.pbxproj:
344         * runtime/JSGenericTypedArrayViewInlines.h:
345         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
346         (JSC::JSGenericTypedArrayView<Adaptor>::put):
347         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
348         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
349         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
350         * runtime/PropertyName.h:
351         (JSC::isCanonicalNumericIndexString):
352
353 2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>
354
355         [JSC] Need to emit SetLocal if we emit MovHint in DFGByteCodeParser
356         https://bugs.webkit.org/show_bug.cgi?id=197584
357
358         Reviewed by Saam Barati.
359
360         In r244864, we emit MovHint for adhocly created GetterCall/SetterCall frame locals in the callee side to make OSR availability analysis's pruning correct.
361         However, we just emit MovHint, and we do not emit SetLocal since we ensured that these locals are already flushed in the same place before. However, MovHint
362         and SetLocal are needed to be a pair in DFGByteCodeParser because we rely on this assumption in SSA conversion phase. SSA conversion phase always emit KillStack
363         just before MovHint's target location even if the MovHint's target is the same to the previously emitted MovHint and SetLocal.
364         This patch emits SetLocal too when emitting MovHint for GetterCall/SetterCall frame locals.
365
366         The example is like this.
367
368             a:  SomeValueNode
369              :  MovHint(@a, loc10)
370             b:  SetLocal(@a, loc10)
371                 ...
372             c:  MovHint(@a, loc10)
373
374         Then, this will be converted to the style in SSA conversion.
375
376             a:  SomeValueNode
377              :  KillStack(loc10)
378             b:  PutStack(@a, loc10)
379                 ...
380             c:  KillStack(loc10)
381
382         Then, @b will be removed later since @c kills it.
383
384         * dfg/DFGByteCodeParser.cpp:
385         (JSC::DFG::ByteCodeParser::inlineCall):
386         * heap/MarkedBlock.cpp:
387         (JSC::MarkedBlock::MarkedBlock):
388         (JSC::MarkedBlock::Handle::stopAllocating):
389         (JSC::MarkedBlock::Handle::resumeAllocating):
390         (JSC::MarkedBlock::aboutToMarkSlow):
391         (JSC::MarkedBlock::Handle::didConsumeFreeList):
392
393 2019-05-03  Devin Rousso  <drousso@apple.com>
394
395         Web Inspector: DOM: rename "low power" to "display composited"
396         https://bugs.webkit.org/show_bug.cgi?id=197296
397
398         Reviewed by Joseph Pecoraro.
399
400         Removed specific ChangeLog entries since it is almost entirely mechanical changes.
401
402         * inspector/protocol/DOM.json:
403
404 2019-05-03  Basuke Suzuki  <Basuke.Suzuki@sony.com>
405
406         [WinCairo] Implement and enable RemoteInspector Server.
407         https://bugs.webkit.org/show_bug.cgi?id=197432
408
409         Reviewed by Ross Kirsling.
410
411         Implement Windows implementation for Socket Backend of RemoteInspector and enable it on WinCairo
412         for experimental feature.
413
414         Also add listener interface for connection between RemoteInspector and RemoteInspectorServer
415         for flexible configuration.
416
417         * PlatformWin.cmake:
418         * inspector/remote/RemoteInspector.h:
419         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
420         (Inspector::RemoteInspectorConnectionClient::didAccept):
421         * inspector/remote/socket/RemoteInspectorServer.cpp:
422         (Inspector::RemoteInspectorServer::connect):
423         (Inspector::RemoteInspectorServer::listenForTargets):
424         (Inspector::RemoteInspectorServer::didAccept):
425         (Inspector::RemoteInspectorServer::dispatchMap):
426         (Inspector::RemoteInspectorServer::start):
427         (Inspector::RemoteInspectorServer::addServerConnection): Deleted.
428         * inspector/remote/socket/RemoteInspectorServer.h:
429         (Inspector::RemoteInspectorServer::RemoteInspectorServer):
430         * inspector/remote/socket/RemoteInspectorSocket.cpp:
431         (Inspector::RemoteInspector::RemoteInspector):
432         (Inspector::RemoteInspector::dispatchMap):
433         (Inspector::RemoteInspector::start):
434         (Inspector::RemoteInspector::stopInternal):
435         (Inspector::RemoteInspector::setServerPort):
436         * inspector/remote/socket/RemoteInspectorSocket.h:
437         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
438         (Inspector::RemoteInspectorSocketEndpoint::listenInet):
439         (Inspector::RemoteInspectorSocketEndpoint::getPort const):
440         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
441         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
442         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
443         (Inspector::Socket::init): Added.
444         (Inspector::Socket::listen): Signature changed.
445         (Inspector::Socket::getPort): Added.
446         * inspector/remote/socket/win/RemoteInspectorSocketWin.cpp: Added.
447         (Inspector::Socket::init):
448         (Inspector::Socket::Socket::Socket):
449         (Inspector::Socket::Socket::~Socket):
450         (Inspector::Socket::Socket::close):
451         (Inspector::Socket::Socket::operator PlatformSocketType const):
452         (Inspector::Socket::Socket::operator bool const):
453         (Inspector::Socket::Socket::leak):
454         (Inspector::Socket::Socket::create):
455         (Inspector::Socket::setOpt):
456         (Inspector::Socket::setOptEnabled):
457         (Inspector::Socket::enableOpt):
458         (Inspector::Socket::connectTo):
459         (Inspector::Socket::bindAndListen):
460         (Inspector::Socket::connect):
461         (Inspector::Socket::listen):
462         (Inspector::Socket::accept):
463         (Inspector::Socket::createPair):
464         (Inspector::Socket::setup):
465         (Inspector::Socket::isValid):
466         (Inspector::Socket::isListening):
467         (Inspector::Socket::getPort):
468         (Inspector::Socket::read):
469         (Inspector::Socket::write):
470         (Inspector::Socket::close):
471         (Inspector::Socket::preparePolling):
472         (Inspector::Socket::poll):
473         (Inspector::Socket::isReadable):
474         (Inspector::Socket::isWritable):
475         (Inspector::Socket::markWaitingWritable):
476         (Inspector::Socket::clearWaitingWritable):
477
478 2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>
479
480         [JSC] Generator CodeBlock generation should be idempotent
481         https://bugs.webkit.org/show_bug.cgi?id=197552
482
483         Reviewed by Keith Miller.
484
485         ES6 Generator saves and resumes the current execution state. Since ES6 generator can save the execution state at expression
486         granularity (not statement granularity), the saved state involves locals. But if the underlying CodeBlock is jettisoned and
487         recompiled with different code generation option (like, debugger, type profiler etc.), the generated instructions can be largely
488         different and it does not have the same state previously used. If we resume the previously created generator with the newly
489         generator function, resuming is messed up.
490
491             function* gen () { ... }
492             var g = gen();
493             g.next();
494
495             // CodeBlock is destroyed & Debugger is enabled.
496
497             g.next();
498
499         In this patch,
500
501         1. In generatorification, we use index Identifier (localN => Identifier("N")) instead of private symbols to generate the same
502            instructions every time we regenerate the CodeBlock.
503
504         2. We decouple the options which can affect on the generated code (Debugger, TypeProfiler, ControlFlowProfiler) from the BytecodeGenerator,
505            and pass them as a parameter, OptionSet<CodeGeneratorMode>.
506
507         3. Generator ScriptExecutable remembers the previous CodeGeneratorMode and reuses this parameter to regenerate CodeBlock. It means that,
508            even if the debugger is enabled, previously created generators are not debuggable. But newly created generators are debuggable.
509
510         * bytecode/BytecodeGeneratorification.cpp:
511         (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
512         (JSC::BytecodeGeneratorification::run):
513         * bytecode/CodeBlock.cpp:
514         (JSC::CodeBlock::finishCreation):
515         (JSC::CodeBlock::setConstantRegisters):
516         * bytecode/UnlinkedCodeBlock.cpp:
517         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
518         * bytecode/UnlinkedCodeBlock.h:
519         (JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes const):
520         (JSC::UnlinkedCodeBlock::wasCompiledWithTypeProfilerOpcodes const):
521         (JSC::UnlinkedCodeBlock::wasCompiledWithControlFlowProfilerOpcodes const):
522         (JSC::UnlinkedCodeBlock::codeGenerationMode const):
523         * bytecode/UnlinkedEvalCodeBlock.h:
524         * bytecode/UnlinkedFunctionCodeBlock.h:
525         * bytecode/UnlinkedFunctionExecutable.cpp:
526         (JSC::generateUnlinkedFunctionCodeBlock):
527         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
528         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
529         * bytecode/UnlinkedFunctionExecutable.h:
530         * bytecode/UnlinkedGlobalCodeBlock.h:
531         (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
532         * bytecode/UnlinkedModuleProgramCodeBlock.h:
533         * bytecode/UnlinkedProgramCodeBlock.h:
534         * bytecompiler/BytecodeGenerator.cpp:
535         (JSC::BytecodeGenerator::BytecodeGenerator):
536         (JSC::BytecodeGenerator::emitTypeProfilerExpressionInfo):
537         (JSC::BytecodeGenerator::emitProfileType):
538         (JSC::BytecodeGenerator::emitProfileControlFlow):
539         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
540         (JSC::BytecodeGenerator::popLexicalScopeInternal):
541         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
542         (JSC::BytecodeGenerator::emitCall):
543         (JSC::BytecodeGenerator::emitCallVarargs):
544         (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
545         (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
546         (JSC::BytecodeGenerator::emitDebugHook):
547         * bytecompiler/BytecodeGenerator.h:
548         (JSC::BytecodeGenerator::generate):
549         (JSC::BytecodeGenerator::shouldEmitDebugHooks const):
550         (JSC::BytecodeGenerator::shouldEmitTypeProfilerHooks const):
551         (JSC::BytecodeGenerator::shouldEmitControlFlowProfilerHooks const):
552         * bytecompiler/NodesCodegen.cpp:
553         (JSC::PrefixNode::emitResolve):
554         (JSC::EmptyVarExpression::emitBytecode):
555         (JSC::ReturnNode::emitBytecode):
556         (JSC::FunctionNode::emitBytecode):
557         * parser/ParserModes.h:
558         (): Deleted.
559         * parser/SourceCodeKey.h:
560         (JSC::SourceCodeFlags::SourceCodeFlags):
561         (JSC::SourceCodeKey::SourceCodeKey):
562         * runtime/CachedTypes.cpp:
563         (JSC::CachedCodeBlock::isClassContext const):
564         (JSC::CachedCodeBlock::codeGenerationMode const):
565         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
566         (JSC::CachedCodeBlock<CodeBlockType>::encode):
567         (JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const): Deleted.
568         * runtime/CodeCache.cpp:
569         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
570         (JSC::CodeCache::getUnlinkedProgramCodeBlock):
571         (JSC::CodeCache::getUnlinkedEvalCodeBlock):
572         (JSC::CodeCache::getUnlinkedModuleProgramCodeBlock):
573         (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
574         (JSC::generateUnlinkedCodeBlockForFunctions):
575         (JSC::sourceCodeKeyForSerializedBytecode):
576         (JSC::sourceCodeKeyForSerializedProgram):
577         (JSC::sourceCodeKeyForSerializedModule):
578         (JSC::serializeBytecode):
579         * runtime/CodeCache.h:
580         (JSC::generateUnlinkedCodeBlockImpl):
581         (JSC::generateUnlinkedCodeBlock):
582         * runtime/Completion.cpp:
583         (JSC::generateProgramBytecode):
584         (JSC::generateModuleBytecode):
585         * runtime/DirectEvalExecutable.cpp:
586         (JSC::DirectEvalExecutable::create):
587         * runtime/IndirectEvalExecutable.cpp:
588         (JSC::IndirectEvalExecutable::create):
589         * runtime/JSGlobalObject.h:
590         (JSC::JSGlobalObject::defaultCodeGenerationMode const):
591         * runtime/ModuleProgramExecutable.cpp:
592         (JSC::ModuleProgramExecutable::create):
593         * runtime/ProgramExecutable.cpp:
594         (JSC::ProgramExecutable::initializeGlobalProperties):
595         * runtime/ScriptExecutable.cpp:
596         (JSC::ScriptExecutable::ScriptExecutable):
597         (JSC::ScriptExecutable::newCodeBlockFor):
598         * runtime/ScriptExecutable.h:
599         * tools/JSDollarVM.cpp:
600         (JSC::changeDebuggerModeWhenIdle):
601         (JSC::functionEnableDebuggerModeWhenIdle):
602         (JSC::functionDisableDebuggerModeWhenIdle):
603
604 2019-05-03  Devin Rousso  <drousso@apple.com>
605
606         Web Inspector: Record actions performed on WebGL2RenderingContext
607         https://bugs.webkit.org/show_bug.cgi?id=176008
608         <rdar://problem/34213884>
609
610         Reviewed by Joseph Pecoraro.
611
612         * inspector/protocol/Recording.json:
613         * inspector/scripts/codegen/generator.py:
614         Add `canvas-webgl2` as a `Type`.
615
616 2019-05-03  Commit Queue  <commit-queue@webkit.org>
617
618         Unreviewed, rolling out r244881.
619         https://bugs.webkit.org/show_bug.cgi?id=197559
620
621         Breaks compilation of jsconly on linux, breaking compilation
622         for jsc-i386-ews, jsc-mips-ews and jsc-armv7-ews (Requested by
623         guijemont on #webkit).
624
625         Reverted changeset:
626
627         "[CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into
628         WEBKIT_COPY_FILES"
629         https://bugs.webkit.org/show_bug.cgi?id=197174
630         https://trac.webkit.org/changeset/244881
631
632 2019-05-02  Don Olmstead  <don.olmstead@sony.com>
633
634         [CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into WEBKIT_COPY_FILES
635         https://bugs.webkit.org/show_bug.cgi?id=197174
636
637         Reviewed by Alex Christensen.
638
639         Replace WEBKIT_MAKE_FORWARDING_HEADERS with WEBKIT_COPY_FILES and make dependencies
640         for framework headers explicit.
641
642         * CMakeLists.txt:
643
644 2019-05-02  Michael Saboff  <msaboff@apple.com>
645
646         Unreviewed rollout of r244862.
647
648         * runtime/JSObject.cpp:
649         (JSC::JSObject::getOwnPropertyDescriptor):
650
651 2019-05-01  Saam barati  <sbarati@apple.com>
652
653         Baseline JIT should do argument value profiling after checking for stack overflow
654         https://bugs.webkit.org/show_bug.cgi?id=197052
655         <rdar://problem/50009602>
656
657         Reviewed by Yusuke Suzuki.
658
659         Otherwise, we may do value profiling without running a write barrier, which
660         is against the rules of how we do value profiling.
661
662         * jit/JIT.cpp:
663         (JSC::JIT::compileWithoutLinking):
664
665 2019-05-01  Yusuke Suzuki  <ysuzuki@apple.com>
666
667         [JSC] Inlining Getter/Setter should care availability of ad-hocly constructed frame
668         https://bugs.webkit.org/show_bug.cgi?id=197405
669
670         Reviewed by Saam Barati.
671
672         When inlining getter and setter calls, we setup a stack frame which does not appear in the bytecode.
673         Because Inlining can switch on executable, we could have a graph like this.
674
675         BB#0
676             ...
677             30: GetSetter
678             31: MovHint(loc10)
679             32: SetLocal(loc10)
680             33: MovHint(loc9)
681             34: SetLocal(loc9)
682             ...
683             37: GetExecutable(@30)
684             ...
685             41: Switch(@37)
686
687         BB#2
688             42: GetLocal(loc12, bc#7 of caller)
689             ...
690             --> callee: loc9 and loc10 are arguments of callee.
691               ...
692               <HERE, exit to callee, loc9 and loc10 are required in the bytecode>
693
694         When we prune OSR availability at the beginning of BB#2 (bc#7 in the caller), we prune loc9 and loc10's liveness because the caller does not actually have loc9 and loc10.
695         However, when we begin executing the callee, we need OSR exit to be aware of where it can recover the arguments to the setter, loc9 and loc10.
696
697         This patch inserts MovHint at the beginning of callee for a getter / setter stack frame to make arguments (loc9 and loc10 in the above example) recoverable from OSR exit.
698         We also move arity fixup DFG nodes from the caller to the callee, since moved arguments are not live in the caller too.
699
700         Interestingly, this fix also reveals the existing issue in LiveCatchVariablePreservationPhase. We emitted Flush for |this| of InlineCallFrame blindly if we saw InlineCallFrame
701         inside a block which is covered by catch handler. But this is wrong because inlined function can finish its execution within the block, and |this| is completely unrelated to
702         the catch handler if the catch handler is in the outer callee. We already collect all the live locals at the catch handler. And this locals must include arguments too if the
703         catch handler is in inlined function. So, we should not emit Flush for each |this| of seen InlineCallFrame. This emitted Flush may connect unrelated locals in the catch handler
704         to the locals that is only defined and used in the inlined function, and it leads to the results like DFG says the local is live while the bytecode says the local is dead.
705         This results in reading and using garbage in OSR entry because DFG OSR entry needs to fill live DFG values from the stack.
706
707         * dfg/DFGByteCodeParser.cpp:
708         (JSC::DFG::ByteCodeParser::inlineCall):
709         (JSC::DFG::ByteCodeParser::handleGetById):
710         (JSC::DFG::ByteCodeParser::handlePutById):
711         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
712         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
713
714 2019-05-01  Michael Saboff  <msaboff@apple.com>
715
716         ASSERTION FAILED: !m_needExceptionCheck with --validateExceptionChecks=1; ProxyObject.getOwnPropertySlotCommon/JSFunction.callerGetter
717         https://bugs.webkit.org/show_bug.cgi?id=197485
718
719         Reviewed by Saam Barati.
720
721         Added an EXCEPTION_ASSERT after call to getOwnPropertySlot().
722
723         * runtime/JSObject.cpp:
724         (JSC::JSObject::getOwnPropertyDescriptor):
725
726 2019-05-01  Ross Kirsling  <ross.kirsling@sony.com>
727
728         RemoteInspector::updateAutomaticInspectionCandidate should have a default implementation.
729         https://bugs.webkit.org/show_bug.cgi?id=197439
730
731         Reviewed by Devin Rousso.
732
733         On non-Cocoa platforms, automatic inspection is not currently implemented,
734         so updateAutomaticInspectionCandidate falls back to the logic of updateTarget.
735         This logic already existed in three places, so refactor it into a common private method
736         and allow our websocket-based RWI implementation to make use of it too.
737
738         * inspector/remote/RemoteInspector.cpp:
739         (Inspector::RemoteInspector::updateTarget):
740         (Inspector::RemoteInspector::updateTargetMap):
741         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
742         * inspector/remote/RemoteInspector.h:
743         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
744         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
745         * inspector/remote/glib/RemoteInspectorGlib.cpp:
746         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
747         * inspector/remote/socket/RemoteInspectorSocket.cpp:
748         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
749
750 2019-05-01  Darin Adler  <darin@apple.com>
751
752         WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
753         https://bugs.webkit.org/show_bug.cgi?id=195535
754
755         Reviewed by Alexey Proskuryakov.
756
757         * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
758
759         * API/JSStringRef.cpp:
760         (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
761         (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
762         Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
763         since that is the default. Also updated for changes to CompletionResult.
764
765         * runtime/JSGlobalObjectFunctions.cpp:
766         (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
767         and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
768         U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
769         equivalents, since these macros from ICU are correct and efficient.
770
771         * wasm/WasmParser.h:
772         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
773         convertUTF8ToUTF16.
774
775 2019-05-01  Shawn Roberts  <sroberts@apple.com>
776
777         Unreviewed, rolling out r244821.
778
779         Causing
780
781         Reverted changeset:
782
783         "WebKit has too much of its own UTF-8 code and should rely
784         more on ICU's UTF-8 support"
785         https://bugs.webkit.org/show_bug.cgi?id=195535
786         https://trac.webkit.org/changeset/244821
787
788 2019-04-29  Darin Adler  <darin@apple.com>
789
790         WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
791         https://bugs.webkit.org/show_bug.cgi?id=195535
792
793         Reviewed by Alexey Proskuryakov.
794
795         * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
796
797         * API/JSStringRef.cpp:
798         (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
799         (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
800         Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
801         since that is the default. Also updated for changes to CompletionResult.
802
803         * runtime/JSGlobalObjectFunctions.cpp:
804         (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
805         and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
806         U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
807         equivalents, since these macros from ICU are correct and efficient.
808
809         * wasm/WasmParser.h:
810         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
811         convertUTF8ToUTF16.
812
813 2019-04-30  Commit Queue  <commit-queue@webkit.org>
814
815         Unreviewed, rolling out r244806.
816         https://bugs.webkit.org/show_bug.cgi?id=197446
817
818         Causing Test262 and JSC test failures on multiple builds
819         (Requested by ShawnRoberts on #webkit).
820
821         Reverted changeset:
822
823         "TypeArrays should not store properties that are canonical
824         numeric indices"
825         https://bugs.webkit.org/show_bug.cgi?id=197228
826         https://trac.webkit.org/changeset/244806
827
828 2019-04-30  Saam barati  <sbarati@apple.com>
829
830         CodeBlock::m_instructionCount is wrong
831         https://bugs.webkit.org/show_bug.cgi?id=197304
832
833         Reviewed by Yusuke Suzuki.
834
835         What we were calling instructionCount() was wrong, as evidenced by
836         us using it incorrectly both in the sampling profiler and when we
837         dumped bytecode for a given CodeBlock. Prior to the bytecode rewrite,
838         instructionCount() was probably valid to do bounds checks against.
839         However, this is no longer the case. This patch renames what we called
840         instructionCount() to bytecodeCost(). It is now only used to make decisions
841         about inlining and tier up heuristics. I've also named options related to
842         this appropriately.
843         
844         This patch also introduces instructionsSize(). The result of this method
845         is valid to do bounds checks against.
846
847         * bytecode/CodeBlock.cpp:
848         (JSC::CodeBlock::dumpAssumingJITType const):
849         (JSC::CodeBlock::CodeBlock):
850         (JSC::CodeBlock::finishCreation):
851         (JSC::CodeBlock::optimizationThresholdScalingFactor):
852         (JSC::CodeBlock::predictedMachineCodeSize):
853         * bytecode/CodeBlock.h:
854         (JSC::CodeBlock::instructionsSize const):
855         (JSC::CodeBlock::bytecodeCost const):
856         (JSC::CodeBlock::instructionCount const): Deleted.
857         * dfg/DFGByteCodeParser.cpp:
858         (JSC::DFG::ByteCodeParser::inliningCost):
859         (JSC::DFG::ByteCodeParser::getInliningBalance):
860         * dfg/DFGCapabilities.cpp:
861         (JSC::DFG::mightCompileEval):
862         (JSC::DFG::mightCompileProgram):
863         (JSC::DFG::mightCompileFunctionForCall):
864         (JSC::DFG::mightCompileFunctionForConstruct):
865         (JSC::DFG::mightInlineFunctionForCall):
866         (JSC::DFG::mightInlineFunctionForClosureCall):
867         (JSC::DFG::mightInlineFunctionForConstruct):
868         * dfg/DFGCapabilities.h:
869         (JSC::DFG::isSmallEnoughToInlineCodeInto):
870         * dfg/DFGDisassembler.cpp:
871         (JSC::DFG::Disassembler::dumpHeader):
872         * dfg/DFGDriver.cpp:
873         (JSC::DFG::compileImpl):
874         * dfg/DFGPlan.cpp:
875         (JSC::DFG::Plan::compileInThread):
876         * dfg/DFGTierUpCheckInjectionPhase.cpp:
877         (JSC::DFG::TierUpCheckInjectionPhase::run):
878         * ftl/FTLCapabilities.cpp:
879         (JSC::FTL::canCompile):
880         * ftl/FTLCompile.cpp:
881         (JSC::FTL::compile):
882         * ftl/FTLLink.cpp:
883         (JSC::FTL::link):
884         * jit/JIT.cpp:
885         (JSC::JIT::link):
886         * jit/JITDisassembler.cpp:
887         (JSC::JITDisassembler::dumpHeader):
888         * llint/LLIntSlowPaths.cpp:
889         (JSC::LLInt::shouldJIT):
890         * profiler/ProfilerBytecodes.cpp:
891         (JSC::Profiler::Bytecodes::Bytecodes):
892         * runtime/Options.h:
893         * runtime/SamplingProfiler.cpp:
894         (JSC::tryGetBytecodeIndex):
895         (JSC::SamplingProfiler::processUnverifiedStackTraces):
896
897 2019-04-30  Tadeu Zagallo  <tzagallo@apple.com>
898
899         TypeArrays should not store properties that are canonical numeric indices
900         https://bugs.webkit.org/show_bug.cgi?id=197228
901         <rdar://problem/49557381>
902
903         Reviewed by Darin Adler.
904
905         According to the spec[1], TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty
906         if the index is a CanonicalNumericIndexString, but invalid according toIntegerIndexedElementGet
907         and similar functions. I.e., there are a few properties that should not be set in a TypedArray,
908         like NaN, Infinity and -0.
909
910         [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
911
912         * CMakeLists.txt:
913         * JavaScriptCore.xcodeproj/project.pbxproj:
914         * runtime/JSGenericTypedArrayViewInlines.h:
915         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
916         (JSC::JSGenericTypedArrayView<Adaptor>::put):
917         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
918         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
919         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
920         * runtime/JSTypedArrays.cpp:
921         * runtime/PropertyName.h:
922         (JSC::canonicalNumericIndexString):
923
924 2019-04-30  Brian Burg  <bburg@apple.com>
925
926         Web Automation: use a more informative key to indicate automation availability
927         https://bugs.webkit.org/show_bug.cgi?id=197377
928         <rdar://problem/50258069>
929
930         Reviewed by Devin Rousso.
931
932         The existing WIRAutomationEnabledKey does not encode uncertainty.
933         Add a new key that provides an 'Unknown' state, and prefer to use it.
934
935         Since an application's initial listing is sent from a background dispatch queue
936         on Cocoa platforms, this can race with main thread initialization that sets up
937         RemoteInspector::Client. Therefore, the initial listing may not properly represent
938         the client's capabilites because the client is not yet available. Allowing for
939         an "Unknown" state that is later upgraded to Available or Not Available makes it
940         possible to work around this potential race.
941
942         * inspector/remote/RemoteInspectorConstants.h:
943         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
944         (Inspector::RemoteInspector::pushListingsNow):
945
946 2019-04-30  Keith Miller  <keith_miller@apple.com>
947
948         Fix failing ARM64E wasm tests
949         https://bugs.webkit.org/show_bug.cgi?id=197420
950
951         Reviewed by Saam Barati.
952
953         This patch fixes a bug in the slow path of our JS->Wasm IC bridge
954         where we wouldn't untag the link register before tail calling.
955
956         Additionally, this patch fixes a broken assert when using setting
957         Options::useTailCalls=false.
958
959         * bytecompiler/BytecodeGenerator.cpp:
960         (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
961         * wasm/js/WebAssemblyFunction.cpp:
962         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
963
964 2019-04-29  Saam Barati  <sbarati@apple.com>
965
966         Make JITType an enum class
967         https://bugs.webkit.org/show_bug.cgi?id=197394
968
969         Reviewed by Yusuke Suzuki.
970
971         This makes the code more easily searchable.
972
973         * bytecode/CallLinkStatus.cpp:
974         (JSC::CallLinkStatus::computeFor):
975         * bytecode/CodeBlock.cpp:
976         (JSC::CodeBlock::dumpAssumingJITType const):
977         (JSC::CodeBlock::specialOSREntryBlockOrNull):
978         (JSC::timeToLive):
979         (JSC::CodeBlock::propagateTransitions):
980         (JSC::CodeBlock::baselineAlternative):
981         (JSC::CodeBlock::baselineVersion):
982         (JSC::CodeBlock::hasOptimizedReplacement):
983         (JSC::CodeBlock::noticeIncomingCall):
984         (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
985         (JSC::CodeBlock::tallyFrequentExitSites):
986         (JSC::CodeBlock::frameRegisterCount):
987         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
988         * bytecode/CodeBlock.h:
989         (JSC::CodeBlock::jitType const):
990         (JSC::CodeBlock::hasBaselineJITProfiling const):
991         * bytecode/CodeBlockWithJITType.h:
992         (JSC::CodeBlockWithJITType::CodeBlockWithJITType):
993         * bytecode/DeferredSourceDump.cpp:
994         (JSC::DeferredSourceDump::DeferredSourceDump):
995         * bytecode/DeferredSourceDump.h:
996         * bytecode/ExitingJITType.h:
997         (JSC::exitingJITTypeFor):
998         * bytecode/InlineCallFrame.h:
999         (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
1000         * dfg/DFGByteCodeParser.cpp:
1001         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1002         * dfg/DFGDisassembler.cpp:
1003         (JSC::DFG::Disassembler::dumpHeader):
1004         * dfg/DFGDriver.cpp:
1005         (JSC::DFG::compileImpl):
1006         * dfg/DFGGraph.cpp:
1007         (JSC::DFG::Graph::dump):
1008         * dfg/DFGJITCode.cpp:
1009         (JSC::DFG::JITCode::JITCode):
1010         (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
1011         (JSC::DFG::JITCode::optimizeNextInvocation):
1012         (JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
1013         (JSC::DFG::JITCode::optimizeAfterWarmUp):
1014         (JSC::DFG::JITCode::optimizeSoon):
1015         (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
1016         (JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
1017         * dfg/DFGJITFinalizer.cpp:
1018         (JSC::DFG::JITFinalizer::finalize):
1019         (JSC::DFG::JITFinalizer::finalizeFunction):
1020         * dfg/DFGOSREntry.cpp:
1021         (JSC::DFG::prepareOSREntry):
1022         (JSC::DFG::prepareCatchOSREntry):
1023         * dfg/DFGOSRExit.cpp:
1024         (JSC::DFG::OSRExit::executeOSRExit):
1025         (JSC::DFG::reifyInlinedCallFrames):
1026         (JSC::DFG::OSRExit::compileOSRExit):
1027         * dfg/DFGOSRExitCompilerCommon.cpp:
1028         (JSC::DFG::handleExitCounts):
1029         (JSC::DFG::reifyInlinedCallFrames):
1030         (JSC::DFG::adjustAndJumpToTarget):
1031         * dfg/DFGOSRExitCompilerCommon.h:
1032         (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
1033         * dfg/DFGOperations.cpp:
1034         * dfg/DFGThunks.cpp:
1035         (JSC::DFG::osrExitGenerationThunkGenerator):
1036         * dfg/DFGVariableEventStream.cpp:
1037         (JSC::DFG::VariableEventStream::reconstruct const):
1038         * ftl/FTLCompile.cpp:
1039         (JSC::FTL::compile):
1040         * ftl/FTLJITCode.cpp:
1041         (JSC::FTL::JITCode::JITCode):
1042         * ftl/FTLJITFinalizer.cpp:
1043         (JSC::FTL::JITFinalizer::finalizeCommon):
1044         * ftl/FTLLink.cpp:
1045         (JSC::FTL::link):
1046         * ftl/FTLOSRExitCompiler.cpp:
1047         (JSC::FTL::compileFTLOSRExit):
1048         * ftl/FTLThunks.cpp:
1049         (JSC::FTL::genericGenerationThunkGenerator):
1050         * interpreter/CallFrame.cpp:
1051         (JSC::CallFrame::callSiteBitsAreBytecodeOffset const):
1052         (JSC::CallFrame::callSiteBitsAreCodeOriginIndex const):
1053         * interpreter/StackVisitor.cpp:
1054         (JSC::StackVisitor::Frame::dump const):
1055         * jit/AssemblyHelpers.h:
1056         (JSC::AssemblyHelpers::AssemblyHelpers):
1057         * jit/JIT.cpp:
1058         (JSC::JIT::link):
1059         * jit/JITCode.cpp:
1060         (JSC::JITCode::typeName):
1061         (WTF::printInternal):
1062         * jit/JITCode.h:
1063         (JSC::JITCode::bottomTierJIT):
1064         (JSC::JITCode::topTierJIT):
1065         (JSC::JITCode::nextTierJIT):
1066         (JSC::JITCode::isExecutableScript):
1067         (JSC::JITCode::couldBeInterpreted):
1068         (JSC::JITCode::isJIT):
1069         (JSC::JITCode::isOptimizingJIT):
1070         (JSC::JITCode::isBaselineCode):
1071         (JSC::JITCode::jitTypeFor):
1072         * jit/JITDisassembler.cpp:
1073         (JSC::JITDisassembler::dumpHeader):
1074         * jit/JITOperations.cpp:
1075         * jit/JITThunks.cpp:
1076         (JSC::JITThunks::hostFunctionStub):
1077         * jit/JITToDFGDeferredCompilationCallback.cpp:
1078         (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1079         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
1080         * jit/JITWorklist.cpp:
1081         (JSC::JITWorklist::compileLater):
1082         (JSC::JITWorklist::compileNow):
1083         * jit/Repatch.cpp:
1084         (JSC::readPutICCallTarget):
1085         (JSC::ftlThunkAwareRepatchCall):
1086         * llint/LLIntEntrypoint.cpp:
1087         (JSC::LLInt::setFunctionEntrypoint):
1088         (JSC::LLInt::setEvalEntrypoint):
1089         (JSC::LLInt::setProgramEntrypoint):
1090         (JSC::LLInt::setModuleProgramEntrypoint):
1091         * llint/LLIntSlowPaths.cpp:
1092         (JSC::LLInt::jitCompileAndSetHeuristics):
1093         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1094         * runtime/SamplingProfiler.cpp:
1095         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1096         * runtime/SamplingProfiler.h:
1097         * runtime/VM.cpp:
1098         (JSC::jitCodeForCallTrampoline):
1099         (JSC::jitCodeForConstructTrampoline):
1100         * tools/CodeProfile.cpp:
1101         (JSC::CodeProfile::sample):
1102         * tools/JSDollarVM.cpp:
1103         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
1104         (JSC::CallerFrameJITTypeFunctor::jitType):
1105         (JSC::functionLLintTrue):
1106         (JSC::functionJITTrue):
1107
1108 2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>
1109
1110         Unreivewed, fix FTL implementation of r244760
1111         https://bugs.webkit.org/show_bug.cgi?id=197362
1112
1113         Reviewed by Saam Barati.
1114
1115         Looked with Saam. ValueFromBlock from double case block was overridden by NaN thing now.
1116
1117         * ftl/FTLLowerDFGToB3.cpp:
1118         (JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
1119
1120 2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>
1121
1122         normalizeMapKey should normalize NaN to one PureNaN bit pattern to make MapHash same
1123         https://bugs.webkit.org/show_bug.cgi?id=197362
1124
1125         Reviewed by Saam Barati.
1126
1127         Our Map/Set's hash algorithm relies on the bit pattern of JSValue. So our Map/Set has
1128         normalization of the key, which normalizes Int32 / Double etc. But we did not normalize
1129         pure NaNs into one canonicalized pure NaN. So we end up having multiple different pure NaNs
1130         in one Map/Set. This patch normalizes NaN into one jsNaN(), which uses PNaN for the representation.
1131
1132         * dfg/DFGSpeculativeJIT.cpp:
1133         (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
1134         * ftl/FTLLowerDFGToB3.cpp:
1135         (JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
1136         * runtime/HashMapImpl.h:
1137         (JSC::normalizeMapKey):
1138
1139 2019-04-29  Alex Christensen  <achristensen@webkit.org>
1140
1141         <rdar://problem/50299396> Fix internal High Sierra build
1142         https://bugs.webkit.org/show_bug.cgi?id=197388
1143
1144         * Configurations/Base.xcconfig:
1145
1146 2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>
1147
1148         JITStubRoutineSet wastes 180KB of HashTable capacity on can.com
1149         https://bugs.webkit.org/show_bug.cgi?id=186732
1150
1151         Reviewed by Saam Barati.
1152
1153         Our current mechanism of JITStubRoutineSet consumes more memory than needed. Basically we have HashMap<uintptr_t, StubRoutine*> and register
1154         each executable address by 16 byte to this entry. So if your StubRoutine has 128bytes, it just adds 8 entries to this hash table.
1155         In Gmail, we see a ~2MB table size.
1156
1157         Instead, this patch uses Vector<pair<uintptr_t, StubRoutine*>> and performs binary search onto this sorted vector. Before conservative
1158         scanning, we sort this vector. And doing binary search with the sorted vector to find executing stub routines from the conservative roots.
1159         This vector includes uintptr_t startAddress to make binary searching fast.
1160
1161         Large amount of conservative scan should be filtered by range check, so I think binary search here is OK, but we can decide based on what the
1162         performance bots say.
1163
1164         * heap/Heap.cpp:
1165         (JSC::Heap::addCoreConstraints):
1166         * heap/JITStubRoutineSet.cpp:
1167         (JSC::JITStubRoutineSet::~JITStubRoutineSet):
1168         (JSC::JITStubRoutineSet::add):
1169         (JSC::JITStubRoutineSet::prepareForConservativeScan):
1170         (JSC::JITStubRoutineSet::clearMarks):
1171         (JSC::JITStubRoutineSet::markSlow):
1172         (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
1173         (JSC::JITStubRoutineSet::traceMarkedStubRoutines):
1174         * heap/JITStubRoutineSet.h:
1175         (JSC::JITStubRoutineSet::mark):
1176         (JSC::JITStubRoutineSet::prepareForConservativeScan):
1177         (JSC::JITStubRoutineSet::size const): Deleted.
1178         (JSC::JITStubRoutineSet::at const): Deleted.
1179
1180 2019-04-29  Basuke Suzuki  <Basuke.Suzuki@sony.com>
1181
1182         [Win] Add flag to enable version information stamping and disable by default.
1183         https://bugs.webkit.org/show_bug.cgi?id=197249
1184         <rdar://problem/50224412>
1185
1186         Reviewed by Ross Kirsling.
1187
1188         This feature is only used in AppleWin port. Add flag for this task and make it OFF by default.
1189         Then enable it by default on AppleWin.
1190
1191         * CMakeLists.txt:
1192
1193 2019-04-26  Keith Rollin  <krollin@apple.com>
1194
1195         Enable new build rule for post-processing headers when using XCBuild
1196         https://bugs.webkit.org/show_bug.cgi?id=197340
1197         <rdar://problem/50226685>
1198
1199         Reviewed by Brent Fulgham.
1200
1201         In Bug 197116, we conditionally disabled the old method for
1202         post-processing header files when we are using the new XCBuild build
1203         system. This check-in conditionally enables the new post-processing
1204         facility. Note that the old system is disabled and the new system
1205         enabled only when the USE_NEW_BUILD_SYSTEM environment variable is set
1206         to YES.
1207
1208         * Configurations/JavaScriptCore.xcconfig:
1209
1210 2019-04-26  Jessie Berlin  <jberlin@webkit.org>
1211
1212         Add new mac target numbers
1213         https://bugs.webkit.org/show_bug.cgi?id=197313
1214
1215         Reviewed by Alex Christensen.
1216
1217         * Configurations/Version.xcconfig:
1218         * Configurations/WebKitTargetConditionals.xcconfig:
1219
1220 2019-04-26  Commit Queue  <commit-queue@webkit.org>
1221
1222         Unreviewed, rolling out r244708.
1223         https://bugs.webkit.org/show_bug.cgi?id=197334
1224
1225         "Broke the debug build" (Requested by rmorisset on #webkit).
1226
1227         Reverted changeset:
1228
1229         "All prototypes should call didBecomePrototype()"
1230         https://bugs.webkit.org/show_bug.cgi?id=196315
1231         https://trac.webkit.org/changeset/244708
1232
1233 2019-04-26  Don Olmstead  <don.olmstead@sony.com>
1234
1235         [CMake] Add WEBKIT_EXECUTABLE macro
1236         https://bugs.webkit.org/show_bug.cgi?id=197206
1237
1238         Reviewed by Konstantin Tokarev.
1239
1240         Migrate to WEBKIT_EXECUTABLE for the jsc and test targets.
1241
1242         * b3/air/testair.cpp:
1243         * b3/testb3.cpp:
1244         * dfg/testdfg.cpp:
1245         * shell/CMakeLists.txt:
1246         * shell/PlatformGTK.cmake:
1247         * shell/PlatformJSCOnly.cmake: Removed.
1248         * shell/PlatformMac.cmake:
1249         * shell/PlatformPlayStation.cmake:
1250         * shell/PlatformWPE.cmake:
1251         * shell/PlatformWin.cmake:
1252
1253 2019-04-25  Yusuke Suzuki  <ysuzuki@apple.com>
1254
1255         [JSC] linkPolymorphicCall now does GC
1256         https://bugs.webkit.org/show_bug.cgi?id=197306
1257
1258         Reviewed by Saam Barati.
1259
1260         Previously, we assumed that linkPolymorphicCall does not perform allocations. So we put CallVariant into a Vector<>.
1261         But now, WebAssemblyFunction's entrypoint generation can allocate JSToWasmICCallee and cause GC. Since CallLinkInfo
1262         does not hold these cells, they can be collected, and we will see dead cells in the middle of linkPolymorphicCall.
1263         We should defer GC for a while in linkPolymorphicCall. We use DeferGCForAWhile instead of DeferGC because the
1264         caller "operationLinkPolymorphicCall" assumes that this function does not cause GC.
1265
1266         * jit/Repatch.cpp:
1267         (JSC::linkPolymorphicCall):
1268
1269 2019-04-26  Robin Morisset  <rmorisset@apple.com>
1270
1271         All prototypes should call didBecomePrototype()
1272         https://bugs.webkit.org/show_bug.cgi?id=196315
1273
1274         Reviewed by Saam Barati.
1275
1276         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
1277
1278         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
1279         create structures with invalid prototypes.
1280         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
1281         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
1282
1283         * runtime/BigIntPrototype.cpp:
1284         (JSC::BigIntPrototype::finishCreation):
1285         * runtime/BooleanPrototype.cpp:
1286         (JSC::BooleanPrototype::finishCreation):
1287         * runtime/DatePrototype.cpp:
1288         (JSC::DatePrototype::finishCreation):
1289         * runtime/ErrorConstructor.cpp:
1290         (JSC::ErrorConstructor::finishCreation):
1291         * runtime/ErrorPrototype.cpp:
1292         (JSC::ErrorPrototype::finishCreation):
1293         * runtime/FunctionConstructor.cpp:
1294         (JSC::FunctionConstructor::finishCreation):
1295         * runtime/FunctionPrototype.cpp:
1296         (JSC::FunctionPrototype::finishCreation):
1297         * runtime/IntlCollatorPrototype.cpp:
1298         (JSC::IntlCollatorPrototype::finishCreation):
1299         * runtime/IntlDateTimeFormatPrototype.cpp:
1300         (JSC::IntlDateTimeFormatPrototype::finishCreation):
1301         * runtime/IntlNumberFormatPrototype.cpp:
1302         (JSC::IntlNumberFormatPrototype::finishCreation):
1303         * runtime/IntlPluralRulesPrototype.cpp:
1304         (JSC::IntlPluralRulesPrototype::finishCreation):
1305         * runtime/JSArrayBufferPrototype.cpp:
1306         (JSC::JSArrayBufferPrototype::finishCreation):
1307         * runtime/JSDataViewPrototype.cpp:
1308         (JSC::JSDataViewPrototype::finishCreation):
1309         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
1310         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
1311         * runtime/JSGlobalObject.cpp:
1312         (JSC::createConsoleProperty):
1313         * runtime/JSPromisePrototype.cpp:
1314         (JSC::JSPromisePrototype::finishCreation):
1315         * runtime/JSTypedArrayViewConstructor.cpp:
1316         (JSC::JSTypedArrayViewConstructor::finishCreation):
1317         * runtime/JSTypedArrayViewPrototype.cpp:
1318         (JSC::JSTypedArrayViewPrototype::finishCreation):
1319         * runtime/NumberPrototype.cpp:
1320         (JSC::NumberPrototype::finishCreation):
1321         * runtime/RegExpPrototype.cpp:
1322         (JSC::RegExpPrototype::finishCreation):
1323         * runtime/StringPrototype.cpp:
1324         (JSC::StringPrototype::finishCreation):
1325         * runtime/Structure.cpp:
1326         (JSC::Structure::isValidPrototype):
1327         (JSC::Structure::changePrototypeTransition):
1328         * runtime/Structure.h:
1329         * runtime/SymbolPrototype.cpp:
1330         (JSC::SymbolPrototype::finishCreation):
1331         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
1332         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
1333         * wasm/js/WebAssemblyInstancePrototype.cpp:
1334         (JSC::WebAssemblyInstancePrototype::finishCreation):
1335         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
1336         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
1337         * wasm/js/WebAssemblyMemoryPrototype.cpp:
1338         (JSC::WebAssemblyMemoryPrototype::finishCreation):
1339         * wasm/js/WebAssemblyModulePrototype.cpp:
1340         (JSC::WebAssemblyModulePrototype::finishCreation):
1341         * wasm/js/WebAssemblyPrototype.cpp:
1342         (JSC::WebAssemblyPrototype::finishCreation):
1343         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
1344         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
1345         * wasm/js/WebAssemblyTablePrototype.cpp:
1346         (JSC::WebAssemblyTablePrototype::finishCreation):
1347
1348 2019-04-26  Don Olmstead  <don.olmstead@sony.com>
1349
1350         Add WTF::findIgnoringASCIICaseWithoutLength to replace strcasestr
1351         https://bugs.webkit.org/show_bug.cgi?id=197291
1352
1353         Reviewed by Konstantin Tokarev.
1354
1355         Replace uses of strcasestr with WTF::findIgnoringASCIICaseWithoutLength.
1356
1357         * API/tests/testapi.cpp:
1358         * assembler/testmasm.cpp:
1359         * b3/air/testair.cpp:
1360         * b3/testb3.cpp:
1361         * dfg/testdfg.cpp:
1362         * dynbench.cpp:
1363
1364 2019-04-25  Fujii Hironori  <Hironori.Fujii@sony.com>
1365
1366         Unreviewed, rolling out r244669.
1367
1368         Windows ports can't clean build.
1369
1370         Reverted changeset:
1371
1372         "[Win] Add flag to enable version information stamping and
1373         disable by default."
1374         https://bugs.webkit.org/show_bug.cgi?id=197249
1375         https://trac.webkit.org/changeset/244669
1376
1377 2019-04-25  Basuke Suzuki  <Basuke.Suzuki@sony.com>
1378
1379         [Win] Add flag to enable version information stamping and disable by default.
1380         https://bugs.webkit.org/show_bug.cgi?id=197249
1381
1382         Reviewed by Ross Kirsling.
1383
1384         This feature is only used in AppleWin port. Add flag for this task and make it OFF by default.
1385         Then enable it by default on AppleWin.
1386
1387         * CMakeLists.txt:
1388
1389 2019-04-25  Timothy Hatcher  <timothy@apple.com>
1390
1391         Disable date and time inputs on iOSMac.
1392         https://bugs.webkit.org/show_bug.cgi?id=197287
1393         rdar://problem/46794376
1394
1395         Reviewed by Wenson Hsieh.
1396
1397         * Configurations/FeatureDefines.xcconfig:
1398
1399 2019-04-25  Alex Christensen  <achristensen@webkit.org>
1400
1401         Fix more builds after r244653
1402         https://bugs.webkit.org/show_bug.cgi?id=197131
1403
1404         * b3/B3Value.h:
1405         There is an older system with libc++ headers that don't have std::conjunction.  Just use constexpr and && instead for the one use of it in WebKit.
1406
1407 2019-04-25  Basuke Suzuki  <Basuke.Suzuki@sony.com>
1408
1409         [RemoteInspector] Fix connection and target identifier types.
1410         https://bugs.webkit.org/show_bug.cgi?id=197243
1411
1412         Reviewed by Ross Kirsling.
1413
1414         Give dedicated type for RemoteControllableTarget's identifier as Inspector::TargetID.
1415
1416         Also rename ClientID type used in Socket backend to ConnectionID because this is the identifier
1417         socket endpoint assign to the newly created connection. The size was changed to uint32_t.
1418         Enough size for managing connections.
1419
1420         * inspector/remote/RemoteConnectionToTarget.cpp:
1421         (Inspector::RemoteConnectionToTarget::setup):
1422         (Inspector::RemoteConnectionToTarget::close):
1423         (Inspector::RemoteConnectionToTarget::targetIdentifier const):
1424         * inspector/remote/RemoteConnectionToTarget.h:
1425         * inspector/remote/RemoteControllableTarget.h:
1426         * inspector/remote/RemoteInspector.cpp:
1427         (Inspector::RemoteInspector::nextAvailableTargetIdentifier):
1428         (Inspector::RemoteInspector::registerTarget):
1429         (Inspector::RemoteInspector::unregisterTarget):
1430         (Inspector::RemoteInspector::updateTarget):
1431         (Inspector::RemoteInspector::setupFailed):
1432         (Inspector::RemoteInspector::setupCompleted):
1433         (Inspector::RemoteInspector::waitingForAutomaticInspection):
1434         (Inspector::RemoteInspector::updateTargetListing):
1435         * inspector/remote/RemoteInspector.h:
1436         * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
1437         (Inspector::RemoteConnectionToTarget::targetIdentifier const):
1438         (Inspector::RemoteConnectionToTarget::setup):
1439         (Inspector::RemoteConnectionToTarget::close):
1440         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
1441         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1442         (Inspector::RemoteInspector::sendMessageToRemote):
1443         (Inspector::RemoteInspector::receivedSetupMessage):
1444         (Inspector::RemoteInspector::receivedDataMessage):
1445         (Inspector::RemoteInspector::receivedDidCloseMessage):
1446         (Inspector::RemoteInspector::receivedIndicateMessage):
1447         (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
1448         * inspector/remote/glib/RemoteInspectorGlib.cpp:
1449         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1450         (Inspector::RemoteInspector::sendMessageToRemote):
1451         (Inspector::RemoteInspector::receivedSetupMessage):
1452         (Inspector::RemoteInspector::receivedDataMessage):
1453         (Inspector::RemoteInspector::receivedCloseMessage):
1454         (Inspector::RemoteInspector::setup):
1455         (Inspector::RemoteInspector::sendMessageToTarget):
1456         * inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
1457         (Inspector::RemoteInspectorConnectionClient::didReceiveWebInspectorEvent):
1458         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
1459         (Inspector::RemoteInspectorConnectionClient::didAccept):
1460         * inspector/remote/socket/RemoteInspectorMessageParser.cpp:
1461         (Inspector::MessageParser::MessageParser):
1462         (Inspector::MessageParser::parse):
1463         * inspector/remote/socket/RemoteInspectorMessageParser.h:
1464         (Inspector::MessageParser::setDidParseMessageListener):
1465         * inspector/remote/socket/RemoteInspectorServer.cpp:
1466         (Inspector::RemoteInspectorServer::didAccept):
1467         (Inspector::RemoteInspectorServer::didClose):
1468         (Inspector::RemoteInspectorServer::dispatchMap):
1469         (Inspector::RemoteInspectorServer::sendWebInspectorEvent):
1470         (Inspector::RemoteInspectorServer::sendCloseEvent):
1471         (Inspector::RemoteInspectorServer::connectionClosed):
1472         * inspector/remote/socket/RemoteInspectorServer.h:
1473         * inspector/remote/socket/RemoteInspectorSocket.cpp:
1474         (Inspector::RemoteInspector::didClose):
1475         (Inspector::RemoteInspector::sendMessageToRemote):
1476         (Inspector::RemoteInspector::setup):
1477         (Inspector::RemoteInspector::sendMessageToTarget):
1478         * inspector/remote/socket/RemoteInspectorSocket.h:
1479         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
1480         (Inspector::RemoteInspectorSocketEndpoint::connectInet):
1481         (Inspector::RemoteInspectorSocketEndpoint::isListening):
1482         (Inspector::RemoteInspectorSocketEndpoint::workerThread):
1483         (Inspector::RemoteInspectorSocketEndpoint::createClient):
1484         (Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
1485         (Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
1486         (Inspector::RemoteInspectorSocketEndpoint::send):
1487         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
1488         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
1489
1490 2019-04-25  Alex Christensen  <achristensen@webkit.org>
1491
1492         Start using C++17
1493         https://bugs.webkit.org/show_bug.cgi?id=197131
1494
1495         Reviewed by Darin Alder.
1496
1497         * Configurations/Base.xcconfig:
1498
1499 2019-04-25  Alex Christensen  <achristensen@webkit.org>
1500
1501         Remove DeprecatedOptional
1502         https://bugs.webkit.org/show_bug.cgi?id=197161
1503
1504         Reviewed by Darin Adler.
1505
1506         We need to keep a symbol exported from JavaScriptCore for binary compatibility with iOS12.
1507         We need this symbol to be in a file that doesn't include anything because libcxx's implementation of
1508         std::optional is actually std::__1::optional, which has a different mangled name.  This change will
1509         prevent protocol errors from being reported if you are running the iOS12 simulator with a custom build of WebKit
1510         and using the web inspector with it, but it's necessary to allow us to start using C++17 in WebKit.
1511
1512         * JavaScriptCore.xcodeproj/project.pbxproj:
1513         * inspector/InspectorBackendDispatcher.cpp:
1514         * inspector/InspectorBackendDispatcher.h:
1515         * inspector/InspectorBackendDispatcherCompatibility.cpp: Added.
1516         (Inspector::BackendDispatcher::reportProtocolError):
1517         * inspector/InspectorBackendDispatcherCompatibility.h: Added.
1518
1519 2019-04-24  Saam Barati  <sbarati@apple.com>
1520
1521         Add SPI callbacks for before and after module execution
1522         https://bugs.webkit.org/show_bug.cgi?id=197244
1523         <rdar://problem/50180511>
1524
1525         Reviewed by Yusuke Suzuki.
1526
1527         This is helpful for clients that want to profile execution of modules
1528         in some way. E.g, if they want to time module execution time.
1529
1530         * API/JSAPIGlobalObject.h:
1531         * API/JSAPIGlobalObject.mm:
1532         (JSC::JSAPIGlobalObject::moduleLoaderEvaluate):
1533         * API/JSContextPrivate.h:
1534         * API/tests/testapi.mm:
1535         (+[JSContextFetchDelegate contextWithBlockForFetch:]):
1536         (-[JSContextFetchDelegate willEvaluateModule:]):
1537         (-[JSContextFetchDelegate didEvaluateModule:]):
1538         (testFetch):
1539         (testFetchWithTwoCycle):
1540         (testFetchWithThreeCycle):
1541         (testLoaderResolvesAbsoluteScriptURL):
1542         (testLoaderRejectsNilScriptURL):
1543         * runtime/JSModuleLoader.cpp:
1544         (JSC::JSModuleLoader::evaluate):
1545         (JSC::JSModuleLoader::evaluateNonVirtual):
1546         * runtime/JSModuleLoader.h:
1547
1548 2019-04-23  Yusuke Suzuki  <ysuzuki@apple.com>
1549
1550         [JSC] Shrink DFG::MinifiedNode
1551         https://bugs.webkit.org/show_bug.cgi?id=197224
1552
1553         Reviewed by Filip Pizlo.
1554
1555         Since it is kept alive with compiled DFG code, we should shrink it to save memory.
1556         If it is effective, we should consider minimizing these OSR exit data more aggressively.
1557
1558         * dfg/DFGMinifiedNode.h:
1559
1560 2019-04-23  Saam Barati  <sbarati@apple.com>
1561
1562         LICM incorrectly assumes it'll never insert a node which provably OSR exits
1563         https://bugs.webkit.org/show_bug.cgi?id=196721
1564         <rdar://problem/49556479> 
1565
1566         Reviewed by Filip Pizlo.
1567
1568         Previously, we assumed LICM could never hoist code that caused us
1569         to provably OSR exit. This is a bad assumption, as we may very well
1570         hoist such code. Obviously hoisting such code is not ideal. We shouldn't
1571         hoist something we provably know will OSR exit. However, this is super rare,
1572         and the phase is written in such a way where it's easier to gracefully
1573         handle this case than to prevent us from hoisting such code.
1574         
1575         If we wanted to ensure we never hoisted code that would provably exit, we'd
1576         have to teach the phase to know when it inserted code that provably exits. I
1577         saw two ways to do that:
1578         1: Save and restore the AI state before actually hoisting.
1579         2: Write an analysis that can determine if such a node would exit.
1580         
1581         (1) is bad because it costs in memory and compile time. (2) will inevitably
1582         have bugs as running into this condition is rare.
1583         
1584         So instead of (1) or (2), I opted to have LICM gracefully handle when
1585         it causes a provable exit. When we encounter this, we mark all blocks
1586         in the loop as !cfaHasVisited and !cfaDidFinish.
1587
1588         * dfg/DFGLICMPhase.cpp:
1589         (JSC::DFG::LICMPhase::attemptHoist):
1590
1591 2019-04-23  Yusuke Suzuki  <ysuzuki@apple.com>
1592
1593         [JSC] Use node index as DFG::MinifiedID
1594         https://bugs.webkit.org/show_bug.cgi?id=197186
1595
1596         Reviewed by Saam Barati.
1597
1598         DFG Nodes can be identified with index if the graph is given. We should use unsigned index as a DFG::MinifiedID's underlying
1599         source instead of Node* to reduce the size of VariableEvent from 16 to 12. Vector<VariableEvent> is the main data in DFG's OSR
1600         tracking. It is kept after DFG compilation is done to make OSR work. We saw that this is allocated with large size in GMail.
1601
1602         * JavaScriptCore.xcodeproj/project.pbxproj:
1603         * bytecode/DataFormat.h:
1604         * bytecode/ValueRecovery.h:
1605         * dfg/DFGGenerationInfo.h:
1606         * dfg/DFGMinifiedID.h:
1607         (JSC::DFG::MinifiedID::MinifiedID):
1608         (JSC::DFG::MinifiedID::operator! const):
1609         (JSC::DFG::MinifiedID::operator== const):
1610         (JSC::DFG::MinifiedID::operator!= const):
1611         (JSC::DFG::MinifiedID::operator< const):
1612         (JSC::DFG::MinifiedID::operator> const):
1613         (JSC::DFG::MinifiedID::operator<= const):
1614         (JSC::DFG::MinifiedID::operator>= const):
1615         (JSC::DFG::MinifiedID::hash const):
1616         (JSC::DFG::MinifiedID::dump const):
1617         (JSC::DFG::MinifiedID::isHashTableDeletedValue const):
1618         (JSC::DFG::MinifiedID::fromBits):
1619         (JSC::DFG::MinifiedID::bits const):
1620         (JSC::DFG::MinifiedID::invalidIndex):
1621         (JSC::DFG::MinifiedID::otherInvalidIndex):
1622         (JSC::DFG::MinifiedID::node const): Deleted.
1623         (JSC::DFG::MinifiedID::invalidID): Deleted.
1624         (JSC::DFG::MinifiedID::otherInvalidID): Deleted.
1625         * dfg/DFGMinifiedIDInlines.h: Copied from Source/JavaScriptCore/dfg/DFGMinifiedNode.cpp.
1626         (JSC::DFG::MinifiedID::MinifiedID):
1627         * dfg/DFGMinifiedNode.cpp:
1628         * dfg/DFGValueSource.h:
1629         (JSC::DFG::ValueSource::ValueSource):
1630         * dfg/DFGVariableEvent.h:
1631         (JSC::DFG::VariableEvent::dataFormat const):
1632
1633 2019-04-23  Keith Rollin  <krollin@apple.com>
1634
1635         Add Xcode version check for Header post-processing scripts
1636         https://bugs.webkit.org/show_bug.cgi?id=197116
1637         <rdar://problem/50058968>
1638
1639         Reviewed by Brent Fulgham.
1640
1641         There are several places in our Xcode projects that post-process
1642         header files after they've been exported. Because of XCBuild, we're
1643         moving to a model where the post-processing is performed at the same
1644         time the header files are exported, rather than as a distinct
1645         post-processing step. This patch disables the distinct step when the
1646         inline processing is available.
1647
1648         In practice, this means prefixing appropriate post-processing Custom
1649         Build phases with:
1650
1651         if [ "${XCODE_VERSION_MAJOR}" -ge "1100" -a "${USE_NEW_BUILD_SYSTEM}" = "YES" ]; then
1652             # In this configuration, post-processing is performed at the same time as copying in the postprocess-header-rule script, so there's no need for this separate step.
1653             exit 0
1654         fi
1655
1656         * JavaScriptCore.xcodeproj/project.pbxproj:
1657
1658 2019-04-23  Commit Queue  <commit-queue@webkit.org>
1659
1660         Unreviewed, rolling out r244558.
1661         https://bugs.webkit.org/show_bug.cgi?id=197219
1662
1663         Causing crashes on iOS Sim Release and Debug (Requested by
1664         ShawnRoberts on #webkit).
1665
1666         Reverted changeset:
1667
1668         "Remove DeprecatedOptional"
1669         https://bugs.webkit.org/show_bug.cgi?id=197161
1670         https://trac.webkit.org/changeset/244558
1671
1672 2019-04-23  Devin Rousso  <drousso@apple.com>
1673
1674         Web Inspector: Uncaught Exception: null is not an object (evaluating 'this.ownerDocument.frameIdentifier')
1675         https://bugs.webkit.org/show_bug.cgi?id=196420
1676         <rdar://problem/49444205>
1677
1678         Reviewed by Timothy Hatcher.
1679
1680         * inspector/protocol/DOM.json:
1681         Modify the existing `frameId` to represent the owner frame of the node, rather than the
1682         frame it holds (in the case of an `<iframe>`).
1683
1684 2019-04-23  Alex Christensen  <achristensen@webkit.org>
1685
1686         Remove DeprecatedOptional
1687         https://bugs.webkit.org/show_bug.cgi?id=197161
1688
1689         Reviewed by Darin Adler.
1690
1691         * inspector/InspectorBackendDispatcher.cpp:
1692         * inspector/InspectorBackendDispatcher.h:
1693
1694 2019-04-22  Yusuke Suzuki  <ysuzuki@apple.com>
1695
1696         [JSC] Use volatile load to populate backing page in MarkedBlock::Footer instead of using holdLock
1697         https://bugs.webkit.org/show_bug.cgi?id=197152
1698
1699         Reviewed by Saam Barati.
1700
1701         Emit volatile load instead of using holdLock to populate backing page in MarkedBlock::Footer.
1702
1703         * heap/BlockDirectory.cpp:
1704         (JSC::BlockDirectory::isPagedOut):
1705         * heap/MarkedBlock.h:
1706         (JSC::MarkedBlock::populatePage const):
1707
1708 2019-04-22  Yusuke Suzuki  <ysuzuki@apple.com>
1709
1710         [JSC] useJIT should subsume useRegExpJIT
1711         https://bugs.webkit.org/show_bug.cgi?id=197153
1712
1713         Reviewed by Alex Christensen.
1714
1715         useJIT should subsume useRegExpJIT. We should immediately disable JIT feature if useJIT = false,
1716         even if useRegExpJIT is true.
1717
1718         * dfg/DFGCapabilities.cpp:
1719         (JSC::DFG::isSupported):
1720         * runtime/Options.cpp:
1721         (JSC::recomputeDependentOptions):
1722         * runtime/RegExp.cpp:
1723         (JSC::RegExp::compile):
1724         (JSC::RegExp::compileMatchOnly):
1725         * runtime/VM.cpp:
1726         (JSC::enableAssembler):
1727         (JSC::VM::canUseRegExpJIT): Deleted.
1728         * runtime/VM.h:
1729
1730 2019-04-22  Basuke Suzuki  <basuke.suzuki@sony.com>
1731
1732         [PlayStation] Restructuring Remote Inspector classes to support multiple platform.
1733         https://bugs.webkit.org/show_bug.cgi?id=197030
1734
1735         Reviewed by Don Olmstead.
1736
1737         Restructuring the PlayStation's RemoteInspector backend which uses native socket for the communication to be ready for WinCairo.
1738
1739         What we did is basically:
1740         - Renamed `remote/playstation/` to `remote/socket/`. This directory is now platform independent implementation of socket backend. 
1741         - Renamed `RemoteInspectorSocket` class to `RemoteInspectorSocketEndpoint`. This class is platform independent and core of the backend.
1742         - Merged `RemoteInspectorSocket{Client|Server}` classes into `RemoteInspectorSocketEndpoint` class because the differences are little.
1743         - Defined a new interface functions in `Inspector::Socket` (new) namespace.
1744         - Moved POSIX socket implementation into `posix\RemoteInspectorSocketPOSIX.{h|cpp}`.
1745
1746         * PlatformPlayStation.cmake:
1747         * inspector/remote/RemoteInspector.h:
1748         * inspector/remote/playstation/RemoteInspectorSocketClient.h: Merged into RemoteInspectorSocketEndpoint.
1749         * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Merged into RemoteInspectorSocketEndpoint.
1750         * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Removed.
1751         * inspector/remote/playstation/RemoteInspectorSocketServer.h: Merged into RemoteInspectorSocketEndpoint.
1752         * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Merged into RemoteInspectorSocketEndpoint.
1753         * inspector/remote/socket/RemoteInspectorConnectionClient.cpp: Renamed from inspector\remote\playstation\RemoteInspectorConnectionClientPlayStation.cpp.
1754         * inspector/remote/socket/RemoteInspectorConnectionClient.h: Renamed from inspector\remote\playstation\RemoteInspectorConnectionClient.h.
1755         (Inspector::RemoteInspectorConnectionClient::didAccept):
1756         * inspector/remote/socket/RemoteInspectorMessageParser.cpp: Renamed from inspector\remote\playstation\RemoteInspectorMessageParserPlayStation.cpp.
1757         * inspector/remote/socket/RemoteInspectorMessageParser.h: Renamed from inspector\remote\playstation\RemoteInspectorMessageParser.h.
1758         * inspector/remote/socket/RemoteInspectorServer.cpp: Renamed from inspector\remote\playstation\RemoteInspectorServerPlayStation.cpp.
1759         (Inspector::RemoteInspectorServer::didAccept):
1760         (Inspector::RemoteInspectorServer::start):
1761         * inspector/remote/socket/RemoteInspectorServer.h: Renamed from inspector\remote\playstation\RemoteInspectorServer.h.
1762         * inspector/remote/socket/RemoteInspectorSocket.cpp: Renamed from inspector\remote\playstation\RemoteInspectorPlayStation.cpp.
1763         (Inspector::RemoteInspector::start):
1764         * inspector/remote/socket/RemoteInspectorSocket.h: Copied from inspector\remote\playstation\RemoteInspectorSocket.h.
1765         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp: Added.
1766         (Inspector::RemoteInspectorSocketEndpoint::RemoteInspectorSocketEndpoint):
1767         (Inspector::RemoteInspectorSocketEndpoint::~RemoteInspectorSocketEndpoint):
1768         (Inspector::RemoteInspectorSocketEndpoint::wakeupWorkerThread):
1769         (Inspector::RemoteInspectorSocketEndpoint::connectInet):
1770         (Inspector::RemoteInspectorSocketEndpoint::listenInet):
1771         (Inspector::RemoteInspectorSocketEndpoint::isListening):
1772         (Inspector::RemoteInspectorSocketEndpoint::workerThread):
1773         (Inspector::RemoteInspectorSocketEndpoint::createClient):
1774         (Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
1775         (Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
1776         (Inspector::RemoteInspectorSocketEndpoint::send):
1777         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
1778         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h: Renamed from inspector\remote\playstation\RemoteInspectorSocket.h.
1779         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp: Added.
1780         (Inspector::Socket::connect):
1781         (Inspector::Socket::listen):
1782         (Inspector::Socket::accept):
1783         (Inspector::Socket::createPair):
1784         (Inspector::Socket::setup):
1785         (Inspector::Socket::isValid):
1786         (Inspector::Socket::isListening):
1787         (Inspector::Socket::read):
1788         (Inspector::Socket::write):
1789         (Inspector::Socket::close):
1790         (Inspector::Socket::preparePolling):
1791         (Inspector::Socket::poll):
1792         (Inspector::Socket::isReadable):
1793         (Inspector::Socket::isWritable):
1794         (Inspector::Socket::markWaitingWritable):
1795         (Inspector::Socket::clearWaitingWritable):
1796
1797 2019-04-20  Yusuke Suzuki  <ysuzuki@apple.com>
1798
1799         Unreviewed, suppress warnings in non Darwin environments
1800
1801         * jit/ExecutableAllocator.cpp:
1802         (JSC::dumpJITMemory):
1803
1804 2019-04-19  Saam Barati  <sbarati@apple.com>
1805
1806         AbstractValue can represent more than int52
1807         https://bugs.webkit.org/show_bug.cgi?id=197118
1808         <rdar://problem/49969960>
1809
1810         Reviewed by Michael Saboff.
1811
1812         Let's analyze this control flow diamond:
1813         
1814         #0
1815         branch #1, #2
1816         
1817         #1:
1818         PutStack(JSValue, loc42)
1819         Jump #3
1820         
1821         #2:
1822         PutStack(Int52, loc42)
1823         Jump #3
1824         
1825         #3:
1826         ...
1827         
1828         Our abstract value for loc42 at the head of #3 will contain an abstract
1829         value that us the union of Int52 with other things. Obviously in the
1830         above program, a GetStack for loc42 would be inavlid, since it might
1831         be loading either JSValue or Int52. However, the abstract interpreter
1832         just tracks what the value could be, and it could be Int52 or JSValue.
1833         
1834         When I did the Int52 refactoring, I expected such things to never happen,
1835         but it turns out it does. We should just allow for this instead of asserting
1836         against it since it's valid IR to do the above.
1837
1838         * bytecode/SpeculatedType.cpp:
1839         (JSC::dumpSpeculation):
1840         * dfg/DFGAbstractValue.cpp:
1841         (JSC::DFG::AbstractValue::checkConsistency const):
1842         * dfg/DFGAbstractValue.h:
1843         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
1844
1845 2019-04-19  Tadeu Zagallo  <tzagallo@apple.com>
1846
1847         Add option to dump JIT memory
1848         https://bugs.webkit.org/show_bug.cgi?id=197062
1849         <rdar://problem/49744332>
1850
1851         Reviewed by Saam Barati.
1852
1853         Dump all writes into JIT memory to the specified file. The format is:
1854         - 64-bit destination address for the write
1855         - 64-bit size of the content written
1856         - Copy of the data that was written to JIT memory
1857
1858         * assembler/LinkBuffer.cpp:
1859         (JSC::LinkBuffer::copyCompactAndLinkCode):
1860         * jit/ExecutableAllocator.cpp:
1861         (JSC::dumpJITMemory):
1862         * jit/ExecutableAllocator.h:
1863         (JSC::performJITMemcpy):
1864         * runtime/Options.h:
1865
1866 2019-04-19  Keith Rollin  <krollin@apple.com>
1867
1868         Add postprocess-header-rule scripts
1869         https://bugs.webkit.org/show_bug.cgi?id=197072
1870         <rdar://problem/50027299>
1871
1872         Reviewed by Brent Fulgham.
1873
1874         Several projects have post-processing build phases where exported
1875         headers are tweaked after they've been copied. This post-processing is
1876         performed via scripts called postprocess-headers.sh. For reasons
1877         related to XCBuild, we are now transitioning to a build process where
1878         the post-processing is performed at the same time as the
1879         exporting/copying. To support this process, add similar scripts named
1880         postprocess-header-rule, which are geared towards processing a single
1881         file at a time rather than all exported files at once. Also add a
1882         build rule that makes use of these scripts. These scripts and build
1883         rules are not used at the moment; they will come into use in an
1884         imminent patch.
1885
1886         Note that I've named these postprocess-header-rule rather than
1887         postprocess-header-rule.sh. Scripts in Tools/Scripts do not have
1888         suffixes indicating how the tool is implemented. Scripts in
1889         per-project Scripts folders appear to be mixed regarding the use of
1890         suffixes. I'm opting here to follow the Tools/Scripts convention, with
1891         the expectation that over time we completely standardize on that.
1892
1893         * JavaScriptCore.xcodeproj/project.pbxproj:
1894         * Scripts/postprocess-header-rule: Added.
1895
1896 2019-04-18  Saam barati  <sbarati@apple.com>
1897
1898         Remove useConcurrentBarriers option
1899         https://bugs.webkit.org/show_bug.cgi?id=197066
1900
1901         Reviewed by Michael Saboff.
1902
1903         This isn't a helpful option as it will lead us to crash when using the
1904         concurrent GC.
1905
1906         * dfg/DFGStoreBarrierClusteringPhase.cpp:
1907         * dfg/DFGStoreBarrierInsertionPhase.cpp:
1908         * jit/AssemblyHelpers.h:
1909         (JSC::AssemblyHelpers::barrierStoreLoadFence):
1910         * runtime/Options.h:
1911
1912 2019-04-17  Saam Barati  <sbarati@apple.com>
1913
1914         Remove deprecated JSScript SPI
1915         https://bugs.webkit.org/show_bug.cgi?id=194909
1916         <rdar://problem/48283499>
1917
1918         Reviewed by Keith Miller.
1919
1920         * API/JSAPIGlobalObject.mm:
1921         (JSC::JSAPIGlobalObject::moduleLoaderFetch):
1922         * API/JSScript.h:
1923         * API/JSScript.mm:
1924         (+[JSScript scriptWithSource:inVirtualMachine:]): Deleted.
1925         (fillBufferWithContentsOfFile): Deleted.
1926         (+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]): Deleted.
1927         (+[JSScript scriptFromUTF8File:inVirtualMachine:withCodeSigning:andBytecodeCache:]): Deleted.
1928         (-[JSScript setSourceURL:]): Deleted.
1929         * API/JSScriptInternal.h:
1930         * API/tests/testapi.mm:
1931         (testFetch):
1932         (testFetchWithTwoCycle):
1933         (testFetchWithThreeCycle):
1934         (testLoaderResolvesAbsoluteScriptURL):
1935         (testImportModuleTwice):
1936         (-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
1937
1938 2019-04-17  Keith Rollin  <krollin@apple.com>
1939
1940         Remove JSCBuiltins.cpp from Copy Headers phase
1941         https://bugs.webkit.org/show_bug.cgi?id=196981
1942         <rdar://problem/49952133>
1943
1944         Reviewed by Alex Christensen.
1945
1946         JSCBuiltins.cpp is not a header and so doesn't need to be in the Copy
1947         Headers phase. Checking its history, it seems to have been added
1948         accidentally at the same time that JSCBuiltins.h was added.
1949
1950         * JavaScriptCore.xcodeproj/project.pbxproj:
1951
1952 2019-04-16  Stephan Szabo  <stephan.szabo@sony.com>
1953
1954         [PlayStation] Update port for system library changes
1955         https://bugs.webkit.org/show_bug.cgi?id=196978
1956
1957         Reviewed by Ross Kirsling.
1958
1959         * shell/playstation/Initializer.cpp:
1960         Add reference to new posix compatibility library.
1961
1962 2019-04-16  Robin Morisset  <rmorisset@apple.com>
1963
1964         [WTF] holdLock should be marked WARN_UNUSED_RETURN
1965         https://bugs.webkit.org/show_bug.cgi?id=196922
1966
1967         Reviewed by Keith Miller.
1968
1969         There was one case where holdLock was used and the result ignored.
1970         From a comment that was deleted in https://bugs.webkit.org/attachment.cgi?id=328438&action=prettypatch, I believe that it is on purpose.
1971         So I brought back a variant of the comment, and made the ignoring of the return explicit.
1972
1973         * heap/BlockDirectory.cpp:
1974         (JSC::BlockDirectory::isPagedOut):
1975
1976 2019-04-16  Caitlin Potter  <caitp@igalia.com>
1977
1978         [JSC] Filter DontEnum properties in ProxyObject::getOwnPropertyNames()
1979         https://bugs.webkit.org/show_bug.cgi?id=176810
1980
1981         Reviewed by Saam Barati.
1982
1983         This adds conditional logic following the invariant checks, to perform
1984         filtering in common uses of getOwnPropertyNames.
1985
1986         While this would ideally only be done in JSPropertyNameEnumerator, adding
1987         the filtering to ProxyObject::performGetOwnPropertyNames maintains the
1988         invariant that the EnumerationMode is properly followed.
1989
1990         This was originally rolled out in r244020, as DontEnum filtering code
1991         in ObjectConstructor.cpp's ownPropertyKeys() had not been removed. It's
1992         now redundant due to being handled in ProxyObject::getOwnPropertyNames().
1993
1994         * runtime/PropertyNameArray.h:
1995         (JSC::PropertyNameArray::reset):
1996         * runtime/ProxyObject.cpp:
1997         (JSC::ProxyObject::performGetOwnPropertyNames):
1998
1999 2019-04-15  Saam barati  <sbarati@apple.com>
2000
2001         Modify how we do SetArgument when we inline varargs calls
2002         https://bugs.webkit.org/show_bug.cgi?id=196712
2003         <rdar://problem/49605012>
2004
2005         Reviewed by Michael Saboff.
2006
2007         When we inline varargs calls, we guarantee that the number of arguments that
2008         go on the stack are somewhere between the "mandatoryMinimum" and the "limit - 1".
2009         However, we can't statically guarantee that the arguments between these two
2010         ranges was filled out by Load/ForwardVarargs. This is because in the general
2011         case we don't know the argument count statically.
2012         
2013         However, we used to always emit SetArgumentDefinitely up to "limit - 1" for
2014         all arguments, even when some arguments aren't guaranteed to be in a valid
2015         state. Emitting these SetArgumentDefinitely were helpful because they let us
2016         handle variable liveness and OSR exit metadata. However, when we converted
2017         to SSA, we ended up emitting a GetStack for each such SetArgumentDefinitely.
2018         
2019         This is wrong, as we can't guarantee such SetArgumentDefinitely nodes are
2020         actually looking at a range of the stack that are guaranteed to be initialized.
2021         This patch introduces a new form of SetArgument node: SetArgumentMaybe. In terms
2022         of OSR exit metadata and variable liveness tracking, it behaves like SetArgumentDefinitely.
2023         
2024         However, it differs in a couple key ways:
2025         1. In ThreadedCPS, GetLocal(@SetArgumentMaybe) is invalid IR, as this implies
2026         you might be loading uninitialized stack. (This same rule applies when you do
2027         the full data flow reachability analysis over CPS Phis.) If someone logically
2028         wanted to emit code like this, the correct node to emit would be GetArgument,
2029         not GetLocal. For similar reasons, PhantomLocal(@SetArgumentMaybe) is also
2030         invalid IR.
2031         2. To track liveness, Flush(@SetArgumentMaybe) is valid, and is the main user
2032         of SetArgumentMaybe.
2033         3. In SSA conversion, we don't lower SetArgumentMaybe to GetStack, as there
2034         should be no data flow user of SetArgumentMaybe.
2035         
2036         SetArgumentDefinitely guarantees that the stack slot is initialized.
2037         SetArgumentMaybe makes no such guarantee.
2038
2039         * dfg/DFGAbstractInterpreterInlines.h:
2040         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2041         * dfg/DFGByteCodeParser.cpp:
2042         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
2043         * dfg/DFGCPSRethreadingPhase.cpp:
2044         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
2045         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2046         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
2047         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
2048         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
2049         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
2050         * dfg/DFGClobberize.h:
2051         (JSC::DFG::clobberize):
2052         * dfg/DFGCommon.h:
2053         * dfg/DFGDoesGC.cpp:
2054         (JSC::DFG::doesGC):
2055         * dfg/DFGFixupPhase.cpp:
2056         (JSC::DFG::FixupPhase::fixupNode):
2057         * dfg/DFGInPlaceAbstractState.cpp:
2058         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
2059         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
2060         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
2061         * dfg/DFGMaximalFlushInsertionPhase.cpp:
2062         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
2063         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
2064         * dfg/DFGMayExit.cpp:
2065         * dfg/DFGNode.cpp:
2066         (JSC::DFG::Node::hasVariableAccessData):
2067         * dfg/DFGNodeType.h:
2068         * dfg/DFGPhantomInsertionPhase.cpp:
2069         * dfg/DFGPredictionPropagationPhase.cpp:
2070         * dfg/DFGSSAConversionPhase.cpp:
2071         (JSC::DFG::SSAConversionPhase::run):
2072         * dfg/DFGSafeToExecute.h:
2073         (JSC::DFG::safeToExecute):
2074         * dfg/DFGSpeculativeJIT32_64.cpp:
2075         (JSC::DFG::SpeculativeJIT::compile):
2076         * dfg/DFGSpeculativeJIT64.cpp:
2077         (JSC::DFG::SpeculativeJIT::compile):
2078         * dfg/DFGValidate.cpp:
2079         * ftl/FTLCapabilities.cpp:
2080         (JSC::FTL::canCompile):
2081
2082 2019-04-15  Commit Queue  <commit-queue@webkit.org>
2083
2084         Unreviewed, rolling out r243672.
2085         https://bugs.webkit.org/show_bug.cgi?id=196952
2086
2087         [JSValue release] should be thread-safe (Requested by
2088         yusukesuzuki on #webkit).
2089
2090         Reverted changeset:
2091
2092         "[JSC] JSWrapperMap should not use Objective-C Weak map
2093         (NSMapTable with NSPointerFunctionsWeakMemory) for
2094         m_cachedObjCWrappers"
2095         https://bugs.webkit.org/show_bug.cgi?id=196392
2096         https://trac.webkit.org/changeset/243672
2097
2098 2019-04-15  Saam barati  <sbarati@apple.com>
2099
2100         SafeToExecute for GetByOffset/GetGetterByOffset/PutByOffset is using the wrong child for the base
2101         https://bugs.webkit.org/show_bug.cgi?id=196945
2102         <rdar://problem/49802750>
2103
2104         Reviewed by Filip Pizlo.
2105
2106         * dfg/DFGSafeToExecute.h:
2107         (JSC::DFG::safeToExecute):
2108
2109 2019-04-15  Robin Morisset  <rmorisset@apple.com>
2110
2111         DFG should be able to constant fold Object.create() with a constant prototype operand
2112         https://bugs.webkit.org/show_bug.cgi?id=196886
2113
2114         Reviewed by Yusuke Suzuki.
2115
2116
2117         It is a fairly simple and limited patch, as it only works when the DFG can prove the exact object used as prototype.
2118         But when it applies it can be a significant win:
2119                                                         Baseline                   Optim                                       
2120         object-create-constant-prototype              3.6082+-0.0979     ^      1.6947+-0.0756        ^ definitely 2.1292x faster
2121         object-create-null                           11.4492+-0.2510     ?     11.5030+-0.2402        ?
2122         object-create-unknown-object-prototype       15.6067+-0.1851     ?     15.7500+-0.2322        ?
2123         object-create-untyped-prototype               8.8873+-0.1240     ?      8.9806+-0.1202        ? might be 1.0105x slower
2124         <geometric>                                   8.6967+-0.1208     ^      7.2408+-0.1367        ^ definitely 1.2011x faster
2125
2126         The only subtlety is that we need to to access the StructureCache concurrently from the compiler thread (see https://bugs.webkit.org/show_bug.cgi?id=186199)
2127         I solved this with a simple lock, taken when the compiler thread tries to read it, and when the main thread tries to modify it.
2128         I expect it to be extremely low contention, but will watch the bots just in case.
2129         The lock is taken neither when the main thread is only reading the cache (it has no-one to race with), nor when the GC purges it of dead entries (it does not free anything while a compiler thread is in the middle of a phase).
2130
2131         * dfg/DFGAbstractInterpreterInlines.h:
2132         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2133         * dfg/DFGConstantFoldingPhase.cpp:
2134         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2135         * runtime/StructureCache.cpp:
2136         (JSC::StructureCache::createEmptyStructure):
2137         (JSC::StructureCache::tryEmptyObjectStructureForPrototypeFromCompilerThread):
2138         * runtime/StructureCache.h:
2139
2140 2019-04-15  Devin Rousso  <drousso@apple.com>
2141
2142         Web Inspector: fake value descriptors for promises add a catch handler, preventing "rejectionhandled" events from being fired
2143         https://bugs.webkit.org/show_bug.cgi?id=196484
2144         <rdar://problem/49114725>
2145
2146         Reviewed by Joseph Pecoraro.
2147
2148         Only add a catch handler when the promise is reachable via a native getter and is known to
2149         have rejected. A non-rejected promise doesn't need a catch handler, and any promise that
2150         isn't reachable via a getter won't actually be reached, as `InjectedScript` doesn't call any
2151         functions, instead only getting the function object itself.
2152
2153         * inspector/InjectedScriptSource.js:
2154         (InjectedScript.prototype._propertyDescriptors.createFakeValueDescriptor):
2155
2156         * inspector/JSInjectedScriptHost.h:
2157         * inspector/JSInjectedScriptHost.cpp:
2158         (Inspector::JSInjectedScriptHost::isPromiseRejectedWithNativeGetterTypeError): Added.
2159         * inspector/JSInjectedScriptHostPrototype.cpp:
2160         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
2161         (Inspector::jsInjectedScriptHostPrototypeFunctionIsPromiseRejectedWithNativeGetterTypeError): Added.
2162
2163         * runtime/ErrorInstance.h:
2164         (JSC::ErrorInstance::setNativeGetterTypeError): Added.
2165         (JSC::ErrorInstance::isNativeGetterTypeError const): Added.
2166
2167         * runtime/Error.h:
2168         (JSC::throwVMGetterTypeError): Added.
2169         * runtime/Error.cpp:
2170         (JSC::createGetterTypeError): Added.
2171         (JSC::throwGetterTypeError): Added.
2172         (JSC::throwDOMAttributeGetterTypeError):
2173
2174 2019-04-15  Robin Morisset  <rmorisset@apple.com>
2175
2176         B3::Value should have different kinds of adjacency lists
2177         https://bugs.webkit.org/show_bug.cgi?id=196091
2178
2179         Reviewed by Filip Pizlo.
2180
2181         The key idea of this optimization is to replace the Vector<Value*, 3> m_children in B3::Value (40 bytes on 64-bits platform) by one of the following:
2182         - Nothing (0 bytes)
2183         - 1 Value* (8 bytes)
2184         - 2 Value* (16 bytes)
2185         - 3 Value* (24 bytes)
2186         - A Vector<Value*, 3>
2187         after the end of the Value object, depending on the kind of the Value.
2188         So for example, when allocating an Add, we would allocate an extra 16 bytes into which to store 2 Values.
2189         This would halve the memory consumption of Const64/Const32/Nop/Identity and a bunch more kinds of values, and reduce by a more moderate amount the memory consumption of the rest of non-varargs values (e.g. Add would go from 72 to 48 bytes).
2190
2191         A few implementation points:
2192         - Even if there is no children, we must remember to allocate at least enough space for replaceWithIdentity to work later. It needs sizeof(Value) (for the object itself) + sizeof(Value*) (for the pointer to its child)
2193         - We must make sure to destroy the vector whenever we destroy a Value which is VarArgs
2194         - We must remember how many elements there are in the case where we did not allocate a Vector. We cannot do it purely by relying on the kind, both for speed reasons and because Return can have either 0 or 1 argument in B3
2195           Thankfully, we have an extra byte of padding to use in the middle of B3::Value
2196         - In order to support clone(), we must have a separate version of allocate, which extracts the opcode from the to-be-cloned object instead of from the call to the constructor
2197         - Speaking of which, we need a special templated function opcodeFromConstructor, because some of the constructors of subclasses of Value don't take an explicit Opcode as argument, typically because they match a single one.
2198         - To maximize performance, we provide specialized versions of child/lastChild/numChildren/children in the subclasses of Value, skipping checks when the actual type of the Value is already known.
2199           This is done through the B3_SPECIALIZE_VALUE_FOR_... defined at the bottom of B3Value.h
2200         - In the constructors of Value, we convert all extra children arguments to Value* eagerly. It is not required for correctness (they will be converted when put into a Vector<Value*> or a Value* in the end), but it helps limit an explosion in the number of template instantiations.
2201         - I moved DeepValueDump::dump from the .h to the .cpp, as there is no good reason to inline it, and recompiling JSC is already slow enough
2202
2203         * JavaScriptCore.xcodeproj/project.pbxproj:
2204         * b3/B3ArgumentRegValue.cpp:
2205         (JSC::B3::ArgumentRegValue::cloneImpl const): Deleted.
2206         * b3/B3ArgumentRegValue.h:
2207         * b3/B3AtomicValue.cpp:
2208         (JSC::B3::AtomicValue::AtomicValue):
2209         (JSC::B3::AtomicValue::cloneImpl const): Deleted.
2210         * b3/B3AtomicValue.h:
2211         * b3/B3BasicBlock.h:
2212         * b3/B3BasicBlockInlines.h:
2213         (JSC::B3::BasicBlock::appendNewNonTerminal): Deleted.
2214         * b3/B3CCallValue.cpp:
2215         (JSC::B3::CCallValue::appendArgs):
2216         (JSC::B3::CCallValue::cloneImpl const): Deleted.
2217         * b3/B3CCallValue.h:
2218         * b3/B3CheckValue.cpp:
2219         (JSC::B3::CheckValue::cloneImpl const): Deleted.
2220         * b3/B3CheckValue.h:
2221         * b3/B3Const32Value.cpp:
2222         (JSC::B3::Const32Value::cloneImpl const): Deleted.
2223         * b3/B3Const32Value.h:
2224         * b3/B3Const64Value.cpp:
2225         (JSC::B3::Const64Value::cloneImpl const): Deleted.
2226         * b3/B3Const64Value.h:
2227         * b3/B3ConstDoubleValue.cpp:
2228         (JSC::B3::ConstDoubleValue::cloneImpl const): Deleted.
2229         * b3/B3ConstDoubleValue.h:
2230         * b3/B3ConstFloatValue.cpp:
2231         (JSC::B3::ConstFloatValue::cloneImpl const): Deleted.
2232         * b3/B3ConstFloatValue.h:
2233         * b3/B3ConstPtrValue.h:
2234         (JSC::B3::ConstPtrValue::opcodeFromConstructor):
2235         * b3/B3FenceValue.cpp:
2236         (JSC::B3::FenceValue::FenceValue):
2237         (JSC::B3::FenceValue::cloneImpl const): Deleted.
2238         * b3/B3FenceValue.h:
2239         * b3/B3MemoryValue.cpp:
2240         (JSC::B3::MemoryValue::MemoryValue):
2241         (JSC::B3::MemoryValue::cloneImpl const): Deleted.
2242         * b3/B3MemoryValue.h:
2243         * b3/B3MoveConstants.cpp:
2244         * b3/B3PatchpointValue.cpp:
2245         (JSC::B3::PatchpointValue::cloneImpl const): Deleted.
2246         * b3/B3PatchpointValue.h:
2247         (JSC::B3::PatchpointValue::opcodeFromConstructor):
2248         * b3/B3Procedure.cpp:
2249         * b3/B3Procedure.h:
2250         * b3/B3ProcedureInlines.h:
2251         (JSC::B3::Procedure::add):
2252         * b3/B3SlotBaseValue.cpp:
2253         (JSC::B3::SlotBaseValue::cloneImpl const): Deleted.
2254         * b3/B3SlotBaseValue.h:
2255         * b3/B3StackmapSpecial.cpp:
2256         (JSC::B3::StackmapSpecial::forEachArgImpl):
2257         (JSC::B3::StackmapSpecial::isValidImpl):
2258         * b3/B3StackmapValue.cpp:
2259         (JSC::B3::StackmapValue::append):
2260         (JSC::B3::StackmapValue::StackmapValue):
2261         * b3/B3StackmapValue.h:
2262         * b3/B3SwitchValue.cpp:
2263         (JSC::B3::SwitchValue::SwitchValue):
2264         (JSC::B3::SwitchValue::cloneImpl const): Deleted.
2265         * b3/B3SwitchValue.h:
2266         (JSC::B3::SwitchValue::opcodeFromConstructor):
2267         * b3/B3UpsilonValue.cpp:
2268         (JSC::B3::UpsilonValue::cloneImpl const): Deleted.
2269         * b3/B3UpsilonValue.h:
2270         * b3/B3Value.cpp:
2271         (JSC::B3::DeepValueDump::dump const):
2272         (JSC::B3::Value::~Value):
2273         (JSC::B3::Value::replaceWithIdentity):
2274         (JSC::B3::Value::replaceWithNopIgnoringType):
2275         (JSC::B3::Value::replaceWithPhi):
2276         (JSC::B3::Value::replaceWithJump):
2277         (JSC::B3::Value::replaceWithOops):
2278         (JSC::B3::Value::replaceWith):
2279         (JSC::B3::Value::invertedCompare const):
2280         (JSC::B3::Value::returnsBool const):
2281         (JSC::B3::Value::cloneImpl const): Deleted.
2282         * b3/B3Value.h:
2283         (JSC::B3::DeepValueDump::dump const): Deleted.
2284         * b3/B3ValueInlines.h:
2285         (JSC::B3::Value::adjacencyListOffset const):
2286         (JSC::B3::Value::cloneImpl const):
2287         * b3/B3VariableValue.cpp:
2288         (JSC::B3::VariableValue::VariableValue):
2289         (JSC::B3::VariableValue::cloneImpl const): Deleted.
2290         * b3/B3VariableValue.h:
2291         * b3/B3WasmAddressValue.cpp:
2292         (JSC::B3::WasmAddressValue::WasmAddressValue):
2293         (JSC::B3::WasmAddressValue::cloneImpl const): Deleted.
2294         * b3/B3WasmAddressValue.h:
2295         * b3/B3WasmBoundsCheckValue.cpp:
2296         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
2297         (JSC::B3::WasmBoundsCheckValue::cloneImpl const): Deleted.
2298         * b3/B3WasmBoundsCheckValue.h:
2299         (JSC::B3::WasmBoundsCheckValue::accepts):
2300         (JSC::B3::WasmBoundsCheckValue::opcodeFromConstructor):
2301         * b3/testb3.cpp:
2302         (JSC::B3::testCallFunctionWithHellaArguments):
2303         (JSC::B3::testCallFunctionWithHellaArguments2):
2304         (JSC::B3::testCallFunctionWithHellaArguments3):
2305         (JSC::B3::testCallFunctionWithHellaDoubleArguments):
2306         (JSC::B3::testCallFunctionWithHellaFloatArguments):
2307         * ftl/FTLOutput.h:
2308         (JSC::FTL::Output::call):
2309
2310 2019-04-15  Tadeu Zagallo  <tzagallo@apple.com>
2311
2312         Bytecode cache should not encode the SourceProvider for UnlinkedFunctionExecutable's classSource
2313         https://bugs.webkit.org/show_bug.cgi?id=196878
2314
2315         Reviewed by Saam Barati.
2316
2317         Every time we encode an (Unlinked)SourceCode, we encode its SourceProvider,
2318         including the full source if it's a StringSourceProvider. This wasn't an issue,
2319         since the SourceCode contains a RefPtr to the SourceProvider, and the Encoder
2320         would avoid encoding the provider multiple times. With the addition of the
2321         incremental cache, each UnlinkedFunctionCodeBlock is encoded in isolation, which
2322         means we can no longer deduplicate it and the full program text was being encoded
2323         multiple times in the cache.
2324         As a work around, this patch adds a custom cached type for encoding the SourceCode
2325         without its provider, and later injects the SourceProvider through the Decoder.
2326
2327         * parser/SourceCode.h:
2328         * parser/UnlinkedSourceCode.h:
2329         (JSC::UnlinkedSourceCode::provider const):
2330         * runtime/CachedTypes.cpp:
2331         (JSC::Decoder::Decoder):
2332         (JSC::Decoder::create):
2333         (JSC::Decoder::provider const):
2334         (JSC::CachedSourceCodeWithoutProvider::encode):
2335         (JSC::CachedSourceCodeWithoutProvider::decode const):
2336         (JSC::decodeCodeBlockImpl):
2337         * runtime/CachedTypes.h:
2338
2339 2019-04-15  Robin Morisset  <rmorisset@apple.com>
2340
2341         MarkedSpace.cpp is not in the Xcode workspace
2342         https://bugs.webkit.org/show_bug.cgi?id=196928
2343
2344         Reviewed by Saam Barati.
2345
2346         * JavaScriptCore.xcodeproj/project.pbxproj:
2347
2348 2019-04-15  Tadeu Zagallo  <tzagallo@apple.com>
2349
2350         Incremental bytecode cache should not append function updates when loaded from memory
2351         https://bugs.webkit.org/show_bug.cgi?id=196865
2352
2353         Reviewed by Filip Pizlo.
2354
2355         Function updates hold the assumption that a function can only be executed/cached
2356         after its containing code block has already been cached. This assumptions does
2357         not hold if the UnlinkedCodeBlock is loaded from memory by the CodeCache, since
2358         we might have two independent SourceProviders executing different paths of the
2359         code and causing the same UnlinkedCodeBlock to be modified in memory.
2360         Use a RefPtr instead of Ref for m_cachedBytecode in ShellSourceProvider to distinguish
2361         between a new, empty cache and a cache that was not loaded and therefore cannot be updated.
2362
2363         * jsc.cpp:
2364         (ShellSourceProvider::ShellSourceProvider):
2365
2366 2019-04-15  Saam barati  <sbarati@apple.com>
2367
2368         mergeOSREntryValue is wrong when the incoming value does not match up with the flush format
2369         https://bugs.webkit.org/show_bug.cgi?id=196918
2370
2371         Reviewed by Yusuke Suzuki.
2372
2373         r244238 lead to some debug failures because we were calling checkConsistency()
2374         before doing fixTypeForRepresentation when merging in must handle values in
2375         CFA. This patch fixes that.
2376         
2377         However, as I was reading over mergeOSREntryValue, I realized it was wrong. It
2378         was possible it could merge in a value/type outside of the variable's flushed type.
2379         Once the flush format types are locked in, we can't introduce a type out of
2380         that range. This probably never lead to any crashes as our profiling injection
2381         and speculation decision code is solid. However, what we were doing is clearly
2382         wrong, and something a fuzzer could have found if we fuzzed the must handle
2383         values inside prediction injection. We should do that fuzzing:
2384         https://bugs.webkit.org/show_bug.cgi?id=196924
2385
2386         * dfg/DFGAbstractValue.cpp:
2387         (JSC::DFG::AbstractValue::mergeOSREntryValue):
2388         * dfg/DFGAbstractValue.h:
2389         * dfg/DFGCFAPhase.cpp:
2390         (JSC::DFG::CFAPhase::injectOSR):
2391
2392 2019-04-15  Robin Morisset  <rmorisset@apple.com>
2393
2394         Several structures and enums in the Yarr interpreter can be shrunk
2395         https://bugs.webkit.org/show_bug.cgi?id=196923
2396
2397         Reviewed by Saam Barati.
2398
2399         YarrOp: 88 -> 80
2400         RegularExpression: 40 -> 32
2401         ByteTerm: 56 -> 48
2402         PatternTerm: 56 -> 48
2403
2404         * yarr/RegularExpression.cpp:
2405         * yarr/YarrInterpreter.h:
2406         * yarr/YarrJIT.cpp:
2407         (JSC::Yarr::YarrGenerator::YarrOp::YarrOp):
2408         * yarr/YarrParser.h:
2409         * yarr/YarrPattern.h:
2410
2411 2019-04-15  Devin Rousso  <drousso@apple.com>
2412
2413         Web Inspector: REGRESSION(r244172): crash when trying to add extra domain while inspecting JSContext
2414         https://bugs.webkit.org/show_bug.cgi?id=196925
2415         <rdar://problem/49873994>
2416
2417         Reviewed by Joseph Pecoraro.
2418
2419         Move the logic for creating the `InspectorAgent` and `InspectorDebuggerAgent` into separate
2420         functions so that callers can be guaranteed to have a valid instance of the agent.
2421
2422         * inspector/JSGlobalObjectInspectorController.h:
2423         * inspector/JSGlobalObjectInspectorController.cpp:
2424         (Inspector::JSGlobalObjectInspectorController::connectFrontend):
2425         (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
2426         (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
2427         (Inspector::JSGlobalObjectInspectorController::ensureInspectorAgent): Added.
2428         (Inspector::JSGlobalObjectInspectorController::ensureDebuggerAgent): Added.
2429         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
2430
2431 2019-04-14  Don Olmstead  <don.olmstead@sony.com>
2432
2433         [CMake] JavaScriptCore derived sources should only be referenced inside JavaScriptCore
2434         https://bugs.webkit.org/show_bug.cgi?id=196742
2435
2436         Reviewed by Konstantin Tokarev.
2437
2438         Migrate to using JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOURCES_JAVASCRIPTCORE_DIR
2439         to support moving the JavaScriptCore derived sources outside of a shared directory.
2440
2441         Also use JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOUCES_DIR.
2442
2443         * CMakeLists.txt:
2444
2445 2019-04-13  Tadeu Zagallo  <tzagallo@apple.com>
2446
2447         CodeCache should check that the UnlinkedCodeBlock was successfully created before caching it
2448         https://bugs.webkit.org/show_bug.cgi?id=196880
2449
2450         Reviewed by Yusuke Suzuki.
2451
2452         CodeCache should not tell the SourceProvider to cache the bytecode if it failed
2453         to create the UnlinkedCodeBlock.
2454
2455         * runtime/CodeCache.cpp:
2456         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
2457
2458 2019-04-12  Saam barati  <sbarati@apple.com>
2459
2460         r244079 logically broke shouldSpeculateInt52
2461         https://bugs.webkit.org/show_bug.cgi?id=196884
2462
2463         Reviewed by Yusuke Suzuki.
2464
2465         In r244079, I changed shouldSpeculateInt52 to only return true
2466         when the prediction is isAnyInt52Speculation(). However, it was
2467         wrong to not to include SpecInt32 in this for two reasons:
2468
2469         1. We diligently write code that first checks if we should speculate Int32.
2470         For example:
2471         if (shouldSpeculateInt32()) ... 
2472         else if (shouldSpeculateInt52()) ...
2473
2474         It would be wrong not to fall back to Int52 if we're dealing with the union of
2475         Int32 and Int52.
2476
2477         It would be a performance mistake to not include Int32 here because
2478         data flow can easily tell us that we have variables that are the union
2479         of Int32 and Int52 values. It's better to speculate Int52 than Double
2480         in that situation.
2481
2482         2. We also write code where we ask if the inputs can be Int52, e.g, if
2483         we know via profiling that an Add overflows, we may not emit an Int32 add.
2484         However, we only emit such an add if both inputs can be Int52, and Int32
2485         can trivially become Int52.
2486
2487        This patch recovers the 0.5-1% regression r244079 caused on JetStream 2.
2488
2489         * bytecode/SpeculatedType.h:
2490         (JSC::isInt32SpeculationForArithmetic):
2491         (JSC::isInt32OrBooleanSpeculationForArithmetic):
2492         (JSC::isInt32OrInt52Speculation):
2493         * dfg/DFGFixupPhase.cpp:
2494         (JSC::DFG::FixupPhase::observeUseKindOnNode):
2495         * dfg/DFGNode.h:
2496         (JSC::DFG::Node::shouldSpeculateInt52):
2497         * dfg/DFGPredictionPropagationPhase.cpp:
2498         * dfg/DFGVariableAccessData.cpp:
2499         (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
2500
2501 2019-04-12  Saam barati  <sbarati@apple.com>
2502
2503         Unreviewed. Build fix after r244233.
2504
2505         * assembler/CPU.cpp:
2506
2507 2019-04-12  Saam barati  <sbarati@apple.com>
2508
2509         Sometimes we need to user fewer CPUs in our threading calculations
2510         https://bugs.webkit.org/show_bug.cgi?id=196794
2511         <rdar://problem/49389497>
2512
2513         Reviewed by Yusuke Suzuki.
2514
2515         * JavaScriptCore.xcodeproj/project.pbxproj:
2516         * Sources.txt:
2517         * assembler/CPU.cpp: Added.
2518         (JSC::isKernTCSMAvailable):
2519         (JSC::enableKernTCSM):
2520         (JSC::kernTCSMAwareNumberOfProcessorCores):
2521         * assembler/CPU.h:
2522         (JSC::isKernTCSMAvailable):
2523         (JSC::enableKernTCSM):
2524         (JSC::kernTCSMAwareNumberOfProcessorCores):
2525         * heap/MachineStackMarker.h:
2526         (JSC::MachineThreads::addCurrentThread):
2527         * runtime/JSLock.cpp:
2528         (JSC::JSLock::didAcquireLock):
2529         * runtime/Options.cpp:
2530         (JSC::computeNumberOfWorkerThreads):
2531         (JSC::computePriorityDeltaOfWorkerThreads):
2532         * wasm/WasmWorklist.cpp:
2533         (JSC::Wasm::Worklist::Worklist):
2534
2535 2019-04-12  Robin Morisset  <rmorisset@apple.com>
2536
2537         Use padding at end of ArrayBuffer
2538         https://bugs.webkit.org/show_bug.cgi?id=196823
2539
2540         Reviewed by Filip Pizlo.
2541
2542         * runtime/ArrayBuffer.h:
2543
2544 2019-04-11  Yusuke Suzuki  <ysuzuki@apple.com>
2545
2546         [JSC] op_has_indexed_property should not assume subscript part is Uint32
2547         https://bugs.webkit.org/show_bug.cgi?id=196850
2548
2549         Reviewed by Saam Barati.
2550
2551         op_has_indexed_property assumed that subscript part is always Uint32. However, this is just a load from non-constant RegisterID,
2552         DFG can store it in double format and can perform OSR exit. op_has_indexed_property should not assume that.
2553         In this patch, instead, we check it with isAnyInt and get uint32_t from AnyInt.
2554
2555         * jit/JITOpcodes.cpp:
2556         (JSC::JIT::emit_op_has_indexed_property):
2557         * jit/JITOpcodes32_64.cpp:
2558         (JSC::JIT::emit_op_has_indexed_property):
2559         * jit/JITOperations.cpp:
2560         * runtime/CommonSlowPaths.cpp:
2561         (JSC::SLOW_PATH_DECL):
2562
2563 2019-04-11  Saam barati  <sbarati@apple.com>
2564
2565         Remove invalid assertion in operationInstanceOfCustom
2566         https://bugs.webkit.org/show_bug.cgi?id=196842
2567         <rdar://problem/49725493>
2568
2569         Reviewed by Michael Saboff.
2570
2571         In the generated JIT code, we go to the slow path when the incoming function
2572         isn't the Node's CodeOrigin's functionProtoHasInstanceSymbolFunction. However,
2573         in the JIT operation, we were asserting against exec->lexicalGlobalObject()'s
2574         functionProtoHasInstanceSymbolFunction. That assertion might be wrong when
2575         inlining across global objects as exec->lexicalGlobalObject() uses the machine
2576         frame for procuring the global object. There is no harm when this assertion fails
2577         as we just execute the slow path. This patch removes the assertion. (However, this
2578         does shed light on the deficiency in our exec->lexicalGlobalObject() function with
2579         respect to inlining. However, this isn't new -- we've known about this for a while.)
2580
2581         * jit/JITOperations.cpp:
2582
2583 2019-04-11  Michael Saboff  <msaboff@apple.com>
2584
2585         Improve the Inline Cache Stats code
2586         https://bugs.webkit.org/show_bug.cgi?id=196836
2587
2588         Reviewed by Saam Barati.
2589
2590         Needed to handle the case where the Identifier could be null, for example with InstanceOfAddAccessCase
2591         and InstanceOfReplaceWithJump.
2592
2593         Added the ability to log the location of a GetBy and PutBy property as either on self or up the
2594         protocol chain.
2595
2596         * jit/ICStats.cpp:
2597         (JSC::ICEvent::operator< const):
2598         (JSC::ICEvent::dump const):
2599         * jit/ICStats.h:
2600         (JSC::ICEvent::ICEvent):
2601         (JSC::ICEvent::hash const):
2602         * jit/JITOperations.cpp:
2603         * jit/Repatch.cpp:
2604         (JSC::tryCacheGetByID):
2605         (JSC::tryCachePutByID):
2606         (JSC::tryCacheInByID):
2607
2608 2019-04-11  Devin Rousso  <drousso@apple.com>
2609
2610         Web Inspector: Timelines: can't reliably stop/start a recording
2611         https://bugs.webkit.org/show_bug.cgi?id=196778
2612         <rdar://problem/47606798>
2613
2614         Reviewed by Timothy Hatcher.
2615
2616         * inspector/protocol/ScriptProfiler.json:
2617         * inspector/protocol/Timeline.json:
2618         It is possible to determine when programmatic capturing starts/stops in the frontend based
2619         on the state when the backend causes the state to change, such as if the state is "inactive"
2620         when the frontend is told that the backend has started capturing.
2621
2622         * inspector/protocol/CPUProfiler.json:
2623         * inspector/protocol/Memory.json:
2624         Send an end timestamp to match other instruments.
2625
2626         * inspector/JSGlobalObjectConsoleClient.cpp:
2627         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
2628         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
2629
2630         * inspector/agents/InspectorScriptProfilerAgent.h:
2631         * inspector/agents/InspectorScriptProfilerAgent.cpp:
2632         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
2633         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
2634         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.
2635
2636 2019-04-11  Saam barati  <sbarati@apple.com>
2637
2638         Rename SetArgument to SetArgumentDefinitely
2639         https://bugs.webkit.org/show_bug.cgi?id=196828
2640
2641         Reviewed by Yusuke Suzuki.
2642
2643         This is in preparation for https://bugs.webkit.org/show_bug.cgi?id=196712
2644         where we will introduce a node named SetArgumentMaybe. Doing this refactoring
2645         first will make reviewing that other patch easier.
2646
2647         * dfg/DFGAbstractInterpreterInlines.h:
2648         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2649         * dfg/DFGByteCodeParser.cpp:
2650         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
2651         (JSC::DFG::ByteCodeParser::parseBlock):
2652         * dfg/DFGCPSRethreadingPhase.cpp:
2653         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
2654         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2655         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
2656         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
2657         (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
2658         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
2659         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
2660         * dfg/DFGClobberize.h:
2661         (JSC::DFG::clobberize):
2662         * dfg/DFGCommon.h:
2663         * dfg/DFGDoesGC.cpp:
2664         (JSC::DFG::doesGC):
2665         * dfg/DFGFixupPhase.cpp:
2666         (JSC::DFG::FixupPhase::fixupNode):
2667         * dfg/DFGGraph.cpp:
2668         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
2669         * dfg/DFGGraph.h:
2670         * dfg/DFGInPlaceAbstractState.cpp:
2671         (JSC::DFG::InPlaceAbstractState::initialize):
2672         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
2673         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
2674         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
2675         * dfg/DFGMaximalFlushInsertionPhase.cpp:
2676         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
2677         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
2678         * dfg/DFGMayExit.cpp:
2679         * dfg/DFGNode.cpp:
2680         (JSC::DFG::Node::hasVariableAccessData):
2681         * dfg/DFGNode.h:
2682         (JSC::DFG::Node::convertPhantomToPhantomLocal):
2683         * dfg/DFGNodeType.h:
2684         * dfg/DFGOSREntrypointCreationPhase.cpp:
2685         (JSC::DFG::OSREntrypointCreationPhase::run):
2686         * dfg/DFGPhantomInsertionPhase.cpp:
2687         * dfg/DFGPredictionPropagationPhase.cpp:
2688         * dfg/DFGSSAConversionPhase.cpp:
2689         (JSC::DFG::SSAConversionPhase::run):
2690         * dfg/DFGSafeToExecute.h:
2691         (JSC::DFG::safeToExecute):
2692         * dfg/DFGSpeculativeJIT.cpp:
2693         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
2694         * dfg/DFGSpeculativeJIT32_64.cpp:
2695         (JSC::DFG::SpeculativeJIT::compile):
2696         * dfg/DFGSpeculativeJIT64.cpp:
2697         (JSC::DFG::SpeculativeJIT::compile):
2698         * dfg/DFGTypeCheckHoistingPhase.cpp:
2699         (JSC::DFG::TypeCheckHoistingPhase::run):
2700         * dfg/DFGValidate.cpp:
2701         * ftl/FTLCapabilities.cpp:
2702         (JSC::FTL::canCompile):
2703
2704 2019-04-11  Truitt Savell  <tsavell@apple.com>
2705
2706         Unreviewed, rolling out r244158.
2707
2708         Casued 8 inspector/timeline/ test failures.
2709
2710         Reverted changeset:
2711
2712         "Web Inspector: Timelines: can't reliably stop/start a
2713         recording"
2714         https://bugs.webkit.org/show_bug.cgi?id=196778
2715         https://trac.webkit.org/changeset/244158
2716
2717 2019-04-10  Saam Barati  <sbarati@apple.com>
2718
2719         AbstractValue::validateOSREntryValue is wrong for Int52 constants
2720         https://bugs.webkit.org/show_bug.cgi?id=196801
2721         <rdar://problem/49771122>
2722
2723         Reviewed by Yusuke Suzuki.
2724
2725         validateOSREntryValue should not care about the format of the incoming
2726         value for Int52s. This patch normalizes the format of m_value and
2727         the incoming value when comparing them.
2728
2729         * dfg/DFGAbstractValue.h:
2730         (JSC::DFG::AbstractValue::validateOSREntryValue const):
2731
2732 2019-04-10  Saam Barati  <sbarati@apple.com>
2733
2734         ArithSub over Int52 has shouldCheckOverflow as always true
2735         https://bugs.webkit.org/show_bug.cgi?id=196796
2736
2737         Reviewed by Yusuke Suzuki.
2738
2739         AI was checking for ArithSub over Int52 if !shouldCheckOverflow. However,
2740         shouldCheckOverflow is always true, so !shouldCheckOverflow is always
2741         false. We shouldn't check something we assert against.
2742
2743         * dfg/DFGAbstractInterpreterInlines.h:
2744         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2745
2746 2019-04-10  Basuke Suzuki  <basuke.suzuki@sony.com>
2747
2748         [PlayStation] Specify byte order clearly on Remote Inspector Protocol
2749         https://bugs.webkit.org/show_bug.cgi?id=196790
2750
2751         Reviewed by Ross Kirsling.
2752
2753         Original implementation lacks byte order specification. Network byte order is the
2754         good candidate if there's no strong reason to choose other.
2755         Currently no client exists for PlayStation remote inspector protocol, so we can
2756         change the byte order without care.
2757
2758         * inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp:
2759         (Inspector::MessageParser::createMessage):
2760         (Inspector::MessageParser::parse):
2761
2762 2019-04-10  Devin Rousso  <drousso@apple.com>
2763
2764        Web Inspector: Inspector: lazily create the agent
2765        https://bugs.webkit.org/show_bug.cgi?id=195971
2766        <rdar://problem/49039645>
2767
2768        Reviewed by Joseph Pecoraro.
2769
2770        * inspector/JSGlobalObjectInspectorController.cpp:
2771        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
2772        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
2773        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
2774        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
2775
2776        * inspector/agents/InspectorAgent.h:
2777        * inspector/agents/InspectorAgent.cpp:
2778
2779 2019-04-10  Saam Barati  <sbarati@apple.com>
2780
2781         Work around an arm64_32 LLVM miscompile bug
2782         https://bugs.webkit.org/show_bug.cgi?id=196788
2783
2784         Reviewed by Yusuke Suzuki.
2785
2786         * runtime/CachedTypes.cpp:
2787
2788 2019-04-10  Devin Rousso  <drousso@apple.com>
2789
2790         Web Inspector: Timelines: can't reliably stop/start a recording
2791         https://bugs.webkit.org/show_bug.cgi?id=196778
2792         <rdar://problem/47606798>
2793
2794         Reviewed by Timothy Hatcher.
2795
2796         * inspector/protocol/ScriptProfiler.json:
2797         * inspector/protocol/Timeline.json:
2798         It is possible to determine when programmatic capturing starts/stops in the frontend based
2799         on the state when the backend causes the state to change, such as if the state is "inactive"
2800         when the frontend is told that the backend has started capturing.
2801
2802         * inspector/protocol/CPUProfiler.json:
2803         * inspector/protocol/Memory.json:
2804         Send an end timestamp to match other instruments.
2805
2806         * inspector/JSGlobalObjectConsoleClient.cpp:
2807         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
2808         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
2809
2810         * inspector/agents/InspectorScriptProfilerAgent.h:
2811         * inspector/agents/InspectorScriptProfilerAgent.cpp:
2812         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
2813         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
2814         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.
2815
2816 2019-04-10  Tadeu Zagallo  <tzagallo@apple.com>
2817
2818         Unreviewed, fix watch build after r244143
2819         https://bugs.webkit.org/show_bug.cgi?id=195000
2820
2821         The result of `lseek` should be `off_t` rather than `int`.
2822
2823         * jsc.cpp:
2824
2825 2019-04-10  Tadeu Zagallo  <tzagallo@apple.com>
2826
2827         Add support for incremental bytecode cache updates
2828         https://bugs.webkit.org/show_bug.cgi?id=195000
2829
2830         Reviewed by Filip Pizlo.
2831
2832         Add support for incremental updates to the bytecode cache. The cache
2833         is constructed as follows:
2834         - When the cache is empty, the initial payload can be added to the BytecodeCache
2835         by calling BytecodeCache::addGlobalUpdate. This represents the encoded
2836         top-level UnlinkedCodeBlock.
2837         - Afterwards, updates can be added by calling BytecodeCache::addFunctionUpdate.
2838         The update is applied by appending the encoded UnlinkedFunctionCodeBlock
2839         to the existing cache and updating the CachedFunctionExecutableMetadata
2840         and the offset of the new CachedFunctionCodeBlock in the owner CachedFunctionExecutable.
2841
2842         * API/JSScript.mm:
2843         (-[JSScript readCache]):
2844         (-[JSScript isUsingBytecodeCache]):
2845         (-[JSScript init]):
2846         (-[JSScript cachedBytecode]):
2847         (-[JSScript writeCache:]):
2848         * API/JSScriptInternal.h:
2849         * API/JSScriptSourceProvider.h:
2850         * API/JSScriptSourceProvider.mm:
2851         (JSScriptSourceProvider::cachedBytecode const):
2852         * CMakeLists.txt:
2853         * JavaScriptCore.xcodeproj/project.pbxproj:
2854         * Sources.txt:
2855         * bytecode/UnlinkedFunctionExecutable.cpp:
2856         (JSC::generateUnlinkedFunctionCodeBlock):
2857         * jsc.cpp:
2858         (ShellSourceProvider::~ShellSourceProvider):
2859         (ShellSourceProvider::cachePath const):
2860         (ShellSourceProvider::loadBytecode const):
2861         (ShellSourceProvider::ShellSourceProvider):
2862         (ShellSourceProvider::cacheEnabled):
2863         * parser/SourceProvider.h:
2864         (JSC::SourceProvider::cachedBytecode const):
2865         (JSC::SourceProvider::updateCache const):
2866         (JSC::SourceProvider::commitCachedBytecode const):
2867         * runtime/CachePayload.cpp: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
2868         (JSC::CachePayload::makeMappedPayload):
2869         (JSC::CachePayload::makeMallocPayload):
2870         (JSC::CachePayload::makeEmptyPayload):
2871         (JSC::CachePayload::CachePayload):
2872         (JSC::CachePayload::~CachePayload):
2873         (JSC::CachePayload::operator=):
2874         (JSC::CachePayload::freeData):
2875         * runtime/CachePayload.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
2876         (JSC::CachePayload::data const):
2877         (JSC::CachePayload::size const):
2878         (JSC::CachePayload::CachePayload):
2879         * runtime/CacheUpdate.cpp: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
2880         (JSC::CacheUpdate::CacheUpdate):
2881         (JSC::CacheUpdate::operator=):
2882         (JSC::CacheUpdate::isGlobal const):
2883         (JSC::CacheUpdate::asGlobal const):
2884         (JSC::CacheUpdate::asFunction const):
2885         * runtime/CacheUpdate.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
2886         * runtime/CachedBytecode.cpp: Added.
2887         (JSC::CachedBytecode::addGlobalUpdate):
2888         (JSC::CachedBytecode::addFunctionUpdate):
2889         (JSC::CachedBytecode::copyLeafExecutables):
2890         (JSC::CachedBytecode::commitUpdates const):
2891         * runtime/CachedBytecode.h: Added.
2892         (JSC::CachedBytecode::create):
2893         (JSC::CachedBytecode::leafExecutables):
2894         (JSC::CachedBytecode::data const):
2895         (JSC::CachedBytecode::size const):
2896         (JSC::CachedBytecode::hasUpdates const):
2897         (JSC::CachedBytecode::sizeForUpdate const):
2898         (JSC::CachedBytecode::CachedBytecode):
2899         * runtime/CachedTypes.cpp:
2900         (JSC::Encoder::addLeafExecutable):
2901         (JSC::Encoder::release):
2902         (JSC::Decoder::Decoder):
2903         (JSC::Decoder::create):
2904         (JSC::Decoder::size const):
2905         (JSC::Decoder::offsetOf):
2906         (JSC::Decoder::ptrForOffsetFromBase):
2907         (JSC::Decoder::addLeafExecutable):
2908         (JSC::VariableLengthObject::VariableLengthObject):
2909         (JSC::VariableLengthObject::buffer const):
2910         (JSC::CachedPtrOffsets::offsetOffset):
2911         (JSC::CachedWriteBarrierOffsets::ptrOffset):
2912         (JSC::CachedFunctionExecutable::features const):
2913         (JSC::CachedFunctionExecutable::hasCapturedVariables const):
2914         (JSC::CachedFunctionExecutableOffsets::codeBlockForCallOffset):
2915         (JSC::CachedFunctionExecutableOffsets::codeBlockForConstructOffset):
2916         (JSC::CachedFunctionExecutableOffsets::metadataOffset):
2917         (JSC::CachedFunctionExecutable::encode):
2918         (JSC::CachedFunctionExecutable::decode const):
2919         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2920         (JSC::encodeCodeBlock):
2921         (JSC::encodeFunctionCodeBlock):
2922         (JSC::decodeCodeBlockImpl):
2923         (JSC::isCachedBytecodeStillValid):
2924         * runtime/CachedTypes.h:
2925         (JSC::VariableLengthObjectBase::VariableLengthObjectBase):
2926         (JSC::decodeCodeBlock):
2927         * runtime/CodeCache.cpp:
2928         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
2929         (JSC::CodeCache::updateCache):
2930         (JSC::CodeCache::write):
2931         (JSC::writeCodeBlock):
2932         (JSC::serializeBytecode):
2933         * runtime/CodeCache.h:
2934         (JSC::SourceCodeValue::SourceCodeValue):
2935         (JSC::CodeCacheMap::findCacheAndUpdateAge):
2936         (JSC::CodeCacheMap::fetchFromDiskImpl):
2937         * runtime/Completion.cpp:
2938         (JSC::generateProgramBytecode):
2939         (JSC::generateModuleBytecode):
2940         * runtime/Completion.h:
2941         * runtime/LeafExecutable.cpp: Copied from Source/JavaScriptCore/API/JSScriptSourceProvider.mm.
2942         (JSC::LeafExecutable::operator+ const):
2943         * runtime/LeafExecutable.h: Copied from Source/JavaScriptCore/API/JSScriptSourceProvider.mm.
2944         (JSC::LeafExecutable::LeafExecutable):
2945         (JSC::LeafExecutable::base const):
2946
2947 2019-04-10  Michael Catanzaro  <mcatanzaro@igalia.com>
2948
2949         Unreviewed, rolling out r243989.
2950
2951         Broke i686 builds
2952
2953         Reverted changeset:
2954
2955         "[CMake] Detect SSE2 at compile time"
2956         https://bugs.webkit.org/show_bug.cgi?id=196488
2957         https://trac.webkit.org/changeset/243989
2958
2959 2019-04-10  Robin Morisset  <rmorisset@apple.com>
2960
2961         We should clear m_needsOverflowCheck when hitting an exception in defineProperties in ObjectConstructor.cpp
2962         https://bugs.webkit.org/show_bug.cgi?id=196746
2963
2964         Reviewed by Yusuke Suzuki..
2965
2966         It should be safe as in that case we are not completing the operation, and so not going to have any buffer overflow.
2967
2968         * runtime/ObjectConstructor.cpp:
2969         (JSC::defineProperties):
2970
2971 2019-04-10  Antoine Quint  <graouts@apple.com>
2972
2973         Enable Pointer Events on watchOS
2974         https://bugs.webkit.org/show_bug.cgi?id=196771
2975         <rdar://problem/49040909>
2976
2977         Reviewed by Dean Jackson.
2978
2979         * Configurations/FeatureDefines.xcconfig:
2980
2981 2019-04-09  Keith Rollin  <krollin@apple.com>
2982
2983         Unreviewed build maintenance -- update .xcfilelists.
2984
2985         * DerivedSources-input.xcfilelist:
2986
2987 2019-04-09  Ross Kirsling  <ross.kirsling@sony.com>
2988
2989         JSC should build successfully even with -DENABLE_UNIFIED_BUILDS=OFF
2990         https://bugs.webkit.org/show_bug.cgi?id=193073
2991
2992         Reviewed by Keith Miller.
2993
2994         * bytecompiler/BytecodeGenerator.cpp:
2995         (JSC::BytecodeGenerator::emitEqualityOpImpl):
2996         (JSC::BytecodeGenerator::emitEqualityOp): Deleted.
2997         * bytecompiler/BytecodeGenerator.h:
2998         (JSC::BytecodeGenerator::emitEqualityOp):
2999         Factor out the logic that uses the template parameter and keep it in the header.
3000
3001         * jit/JITPropertyAccess.cpp:
3002         List off the template specializations needed by JITOperations.cpp.
3003         This is unfortunate but at least there are only two (x2) by definition?
3004         Trying to do away with this incurs a severe domino effect...
3005
3006         * API/JSValueRef.cpp:
3007         * b3/B3OptimizeAssociativeExpressionTrees.cpp:
3008         * b3/air/AirHandleCalleeSaves.cpp:
3009         * builtins/BuiltinNames.cpp:
3010         * bytecode/AccessCase.cpp:
3011         * bytecode/BytecodeIntrinsicRegistry.cpp:
3012         * bytecode/BytecodeIntrinsicRegistry.h:
3013         * bytecode/BytecodeRewriter.cpp:
3014         * bytecode/BytecodeUseDef.h:
3015         * bytecode/CodeBlock.cpp:
3016         * bytecode/InstanceOfAccessCase.cpp:
3017         * bytecode/MetadataTable.cpp:
3018         * bytecode/PolyProtoAccessChain.cpp:
3019         * bytecode/StructureSet.cpp:
3020         * bytecompiler/NodesCodegen.cpp:
3021         * dfg/DFGCFAPhase.cpp:
3022         * dfg/DFGPureValue.cpp:
3023         * heap/GCSegmentedArray.h:
3024         * heap/HeapInlines.h:
3025         * heap/IsoSubspace.cpp:
3026         * heap/LocalAllocator.cpp:
3027         * heap/LocalAllocator.h:
3028         * heap/LocalAllocatorInlines.h:
3029         * heap/MarkingConstraintSolver.cpp:
3030         * inspector/ScriptArguments.cpp:
3031         (Inspector::ScriptArguments::isEqual const):
3032         * inspector/ScriptCallStackFactory.cpp:
3033         * interpreter/CallFrame.h:
3034         * interpreter/Interpreter.cpp:
3035         * interpreter/StackVisitor.cpp:
3036         * llint/LLIntEntrypoint.cpp:
3037         * runtime/ArrayIteratorPrototype.cpp:
3038         * runtime/BigIntPrototype.cpp:
3039         * runtime/CachedTypes.cpp:
3040         * runtime/ErrorType.cpp:
3041         * runtime/IndexingType.cpp:
3042         * runtime/JSCellInlines.h:
3043         * runtime/JSImmutableButterfly.h:
3044         * runtime/Operations.h:
3045         * runtime/RegExpCachedResult.cpp:
3046         * runtime/RegExpConstructor.cpp:
3047         * runtime/RegExpGlobalData.cpp:
3048         * runtime/StackFrame.h:
3049         * wasm/WasmSignature.cpp:
3050         * wasm/js/JSToWasm.cpp:
3051         * wasm/js/JSToWasmICCallee.cpp:
3052         * wasm/js/WebAssemblyFunction.h:
3053         Fix includes / forward declarations (and a couple of nearby clang warnings).
3054
3055 2019-04-09  Don Olmstead  <don.olmstead@sony.com>
3056
3057         [CMake] Apple builds should use ICU_INCLUDE_DIRS
3058         https://bugs.webkit.org/show_bug.cgi?id=196720
3059
3060         Reviewed by Konstantin Tokarev.
3061
3062         * PlatformMac.cmake:
3063
3064 2019-04-09  Saam barati  <sbarati@apple.com>
3065
3066         Clean up Int52 code and some bugs in it
3067         https://bugs.webkit.org/show_bug.cgi?id=196639
3068         <rdar://problem/49515757>
3069
3070         Reviewed by Yusuke Suzuki.
3071
3072         This patch fixes bugs in our Int52 code. The primary change in this patch is
3073         adopting a segregated type lattice for Int52. Previously, for Int52 values,
3074         we represented them with SpecInt32Only and SpecInt52Only. For an Int52,
3075         SpecInt32Only meant that the value is in int32 range. And SpecInt52Only meant
3076         that the is outside of the int32 range.
3077         
3078         However, this got confusing because we reused SpecInt32Only both for JSValue
3079         representations and Int52 representations. This actually lead to some bugs.
3080         
3081         1. It's possible that roundtripping through Int52 representation would say
3082         it produces the wrong type. For example, consider this program and how we
3083         used to annotate types in AI:
3084         a: JSConstant(10.0) => m_type is SpecAnyIntAsDouble
3085         b: Int52Rep(@a) => m_type is SpecInt52Only
3086         c: ValueRep(@b) => m_type is SpecAnyIntAsDouble
3087         
3088         In AI, for the above program, we'd say that @c produces SpecAnyIntAsDouble.
3089         However, the execution semantics are such that it'd actually produce a boxed
3090         Int32. This patch fixes the bug where we'd say that Int52Rep over SpecAnyIntAsDouble
3091         would produce SpecInt52Only. This is clearly wrong, as SpecAnyIntAsDouble can
3092         mean an int value in either int32 or int52 range.
3093         
3094         2. AsbstractValue::validateTypeAcceptingBoxedInt52 was wrong in how it
3095         accepted Int52 values. It was wrong in two different ways:
3096         a: If the AbstractValue's type was SpecInt52Only, and the incoming value
3097         was a boxed double, but represented a value in int32 range, the incoming
3098         value would incorrectly validate as being acceptable. However, we should
3099         have rejected this value.
3100         b: If the AbstractValue's type was SpecInt32Only, and the incoming value
3101         was an Int32 boxed in a double, this would not validate, even though
3102         it should have validated.
3103         
3104         Solving 2 was easiest if we segregated out the Int52 type into its own
3105         lattice. This patch makes a new Int52 lattice, which is composed of
3106         SpecInt32AsInt52 and SpecNonInt32AsInt52.
3107         
3108         The conversion rules are now really simple.
3109         
3110         Int52 rep => JSValue rep
3111         SpecInt32AsInt52 => SpecInt32Only
3112         SpecNonInt32AsInt52 => SpecAnyIntAsDouble
3113         
3114         JSValue rep => Int52 rep
3115         SpecInt32Only => SpecInt32AsInt52
3116         SpecAnyIntAsDouble => SpecInt52Any
3117         
3118         With these rules, the program in (1) will now correctly report that @c
3119         returns SpecInt32Only | SpecAnyIntAsDouble.
3120
3121         * bytecode/SpeculatedType.cpp:
3122         (JSC::dumpSpeculation):
3123         (JSC::speculationToAbbreviatedString):
3124         (JSC::int52AwareSpeculationFromValue):
3125         (JSC::leastUpperBoundOfStrictlyEquivalentSpeculations):
3126         (JSC::speculationFromString):
3127         * bytecode/SpeculatedType.h:
3128         (JSC::isInt32SpeculationForArithmetic):
3129         (JSC::isInt32OrBooleanSpeculationForArithmetic):
3130         (JSC::isAnyInt52Speculation):
3131         (JSC::isIntAnyFormat):
3132         (JSC::isInt52Speculation): Deleted.
3133         (JSC::isAnyIntSpeculation): Deleted.
3134         * dfg/DFGAbstractInterpreterInlines.h:
3135         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3136         * dfg/DFGAbstractValue.cpp:
3137         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
3138         (JSC::DFG::AbstractValue::checkConsistency const):
3139         * dfg/DFGAbstractValue.h:
3140         (JSC::DFG::AbstractValue::isInt52Any const):
3141         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
3142         * dfg/DFGFixupPhase.cpp:
3143         (JSC::DFG::FixupPhase::fixupArithMul):
3144         (JSC::DFG::FixupPhase::fixupNode):
3145         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
3146         (JSC::DFG::FixupPhase::fixupToThis):
3147         (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
3148         (JSC::DFG::FixupPhase::observeUseKindOnNode):
3149         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
3150         (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
3151         (JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue):
3152         (JSC::DFG::FixupPhase::fixupChecksInBlock):
3153         * dfg/DFGGraph.h:
3154         (JSC::DFG::Graph::addShouldSpeculateInt52):
3155         (JSC::DFG::Graph::binaryArithShouldSpeculateInt52):
3156         (JSC::DFG::Graph::unaryArithShouldSpeculateInt52):
3157         (JSC::DFG::Graph::addShouldSpeculateAnyInt): Deleted.
3158         (JSC::DFG::Graph::binaryArithShouldSpeculateAnyInt): Deleted.
3159         (JSC::DFG::Graph::unaryArithShouldSpeculateAnyInt): Deleted.
3160         * dfg/DFGNode.h:
3161         (JSC::DFG::Node::shouldSpeculateInt52):
3162         (JSC::DFG::Node::shouldSpeculateAnyInt): Deleted.
3163         * dfg/DFGPredictionPropagationPhase.cpp:
3164         * dfg/DFGSpeculativeJIT.cpp:
3165         (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
3166         (JSC::DFG::SpeculativeJIT::compileArithAdd):
3167         (JSC::DFG::SpeculativeJIT::compileArithSub):
3168         (JSC::DFG::SpeculativeJIT::compileArithNegate):
3169         * dfg/DFGSpeculativeJIT64.cpp:
3170         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
3171         (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
3172         * dfg/DFGUseKind.h:
3173         (JSC::DFG::typeFilterFor):
3174         * dfg/DFGVariableAccessData.cpp:
3175         (JSC::DFG::VariableAccessData::makePredictionForDoubleFormat):
3176         (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
3177         * ftl/FTLLowerDFGToB3.cpp:
3178         (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
3179         (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
3180         (JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):
3181
3182 2019-04-09  Tadeu Zagallo  <tzagallo@apple.com>
3183
3184         ASSERTION FAILED: !scope.exception() || !hasProperty in JSObject::get
3185         https://bugs.webkit.org/show_bug.cgi?id=196708
3186         <rdar://problem/49556803>
3187
3188         Reviewed by Yusuke Suzuki.
3189
3190         `operationPutToScope` needs to return early if an exception is thrown while
3191         checking if `hasProperty`.
3192
3193         * jit/JITOperations.cpp:
3194
3195 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
3196
3197         [JSC] DFG should respect node's strict flag
3198         https://bugs.webkit.org/show_bug.cgi?id=196617
3199
3200         Reviewed by Saam Barati.
3201
3202         We accidentally use codeBlock->isStrictMode() directly in DFG and FTL. But this is wrong since this CodeBlock is the top level DFG/FTL CodeBlock,
3203         and this code does not respect the isStrictMode flag for the inlined CodeBlocks. In this patch, we start using isStrictModeFor(CodeOrigin) consistently
3204         in DFG and FTL to get the right isStrictMode flag for the DFG node.
3205         And we also split compilePutDynamicVar into compilePutDynamicVarStrict and compilePutDynamicVarNonStrict since (1) it is cleaner than accessing inlined
3206         callframe in the operation function, and (2) it is aligned to the other functions like operationPutByValDirectNonStrict etc.
3207         This bug is discovered by RandomizingFuzzerAgent by expanding the DFG coverage.
3208
3209         * dfg/DFGAbstractInterpreterInlines.h:
3210         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3211         * dfg/DFGConstantFoldingPhase.cpp:
3212         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3213         * dfg/DFGFixupPhase.cpp:
3214         (JSC::DFG::FixupPhase::fixupToThis):
3215         * dfg/DFGOperations.cpp:
3216         * dfg/DFGOperations.h:
3217         * dfg/DFGPredictionPropagationPhase.cpp:
3218         * dfg/DFGSpeculativeJIT.cpp:
3219         (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
3220         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
3221         (JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
3222         (JSC::DFG::SpeculativeJIT::compileToThis):
3223         * dfg/DFGSpeculativeJIT32_64.cpp:
3224         (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
3225         (JSC::DFG::SpeculativeJIT::compile):
3226         * dfg/DFGSpeculativeJIT64.cpp:
3227         (JSC::DFG::SpeculativeJIT::compile):
3228         * ftl/FTLLowerDFGToB3.cpp:
3229         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
3230         (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
3231
3232 2019-04-08  Don Olmstead  <don.olmstead@sony.com>
3233
3234         [CMake][WinCairo] Separate copied headers into different directories
3235         https://bugs.webkit.org/show_bug.cgi?id=196655
3236
3237         Reviewed by Michael Catanzaro.
3238
3239         * CMakeLists.txt:
3240         * shell/PlatformWin.cmake:
3241
3242 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
3243
3244         [JSC] isRope jump in StringSlice should not jump over register allocations
3245         https://bugs.webkit.org/show_bug.cgi?id=196716
3246
3247         Reviewed by Saam Barati.
3248
3249         Jumping over the register allocation code in DFG (like the following) is wrong.
3250
3251             auto jump = m_jit.branchXXX();
3252             {
3253                 GPRTemporary reg(this);
3254                 GPRReg regGPR = reg.gpr();
3255                 ...
3256             }
3257             jump.link(&m_jit);
3258
3259         When GPRTemporary::gpr allocates a new register, it can flush the previous register value into the stack and make the register usable.
3260         Jumping over this register allocation code skips the flushing code, and makes the DFG's stack and register content tracking inconsistent:
3261         DFG thinks that the content is flushed and stored in particular stack slot even while this flushing code is skipped.
3262         In this patch, we perform register allocations before jumping to the slow path based on `isRope` condition in StringSlice.
3263
3264         * dfg/DFGSpeculativeJIT.cpp:
3265         (JSC::DFG::SpeculativeJIT::compileStringSlice):
3266
3267 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
3268
3269         [JSC] to_index_string should not assume incoming value is Uint32
3270         https://bugs.webkit.org/show_bug.cgi?id=196713
3271
3272         Reviewed by Saam Barati.
3273
3274         The slow path of to_index_string assumes that incoming value is Uint32. But we should not have
3275         this assumption since DFG may decide we should have it double format. This patch removes this
3276         assumption, and instead, we should assume that incoming value is AnyInt and the range of this
3277         is within Uint32.
3278
3279         * runtime/CommonSlowPaths.cpp:
3280         (JSC::SLOW_PATH_DECL):
3281
3282 2019-04-08  Justin Fan  <justin_fan@apple.com>
3283
3284         [Web GPU] Fix Web GPU experimental feature on iOS
3285         https://bugs.webkit.org/show_bug.cgi?id=196632
3286
3287         Reviewed by Myles C. Maxfield.
3288
3289         Properly make Web GPU available on iOS 11+.
3290
3291         * Configurations/FeatureDefines.xcconfig:
3292         * Configurations/WebKitTargetConditionals.xcconfig:
3293
3294 2019-04-08  Ross Kirsling  <ross.kirsling@sony.com>
3295
3296         -f[no-]var-tracking-assignments is GCC-only
3297         https://bugs.webkit.org/show_bug.cgi?id=196699
3298
3299         Reviewed by Don Olmstead.
3300
3301         * CMakeLists.txt:
3302         Just remove the build flag altogether -- it supposedly doesn't solve the problem it was meant to
3303         and said problem evidently no longer occurs as of GCC 9.
3304
3305 2019-04-08  Saam Barati  <sbarati@apple.com>
3306
3307         WebAssembly.RuntimeError missing exception check
3308         https://bugs.webkit.org/show_bug.cgi?id=196700
3309         <rdar://problem/49693932>
3310
3311         Reviewed by Yusuke Suzuki.
3312
3313         * wasm/js/JSWebAssemblyRuntimeError.h:
3314         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
3315         (JSC::constructJSWebAssemblyRuntimeError):
3316
3317 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
3318
3319         Unreviewed, rolling in r243948 with test fix
3320         https://bugs.webkit.org/show_bug.cgi?id=196486
3321
3322         * parser/ASTBuilder.h:
3323         (JSC::ASTBuilder::createString):
3324         * parser/Lexer.cpp:
3325         (JSC::Lexer<T>::parseMultilineComment):
3326         (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
3327         (JSC::Lexer<T>::lex): Deleted.
3328         * parser/Lexer.h:
3329         (JSC::Lexer::hasLineTerminatorBeforeToken const):
3330         (JSC::Lexer::setHasLineTerminatorBeforeToken):
3331         (JSC::Lexer<T>::lex):
3332         (JSC::Lexer::prevTerminator const): Deleted.
3333         (JSC::Lexer::setTerminator): Deleted.
3334         * parser/Parser.cpp:
3335         (JSC::Parser<LexerType>::allowAutomaticSemicolon):
3336         (JSC::Parser<LexerType>::parseSingleFunction):
3337         (JSC::Parser<LexerType>::parseStatementListItem):
3338         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
3339         (JSC::Parser<LexerType>::parseFunctionInfo):
3340         (JSC::Parser<LexerType>::parseClass):
3341         (JSC::Parser<LexerType>::parseExportDeclaration):
3342         (JSC::Parser<LexerType>::parseAssignmentExpression):
3343         (JSC::Parser<LexerType>::parseYieldExpression):
3344         (JSC::Parser<LexerType>::parseProperty):
3345         (JSC::Parser<LexerType>::parsePrimaryExpression):
3346         (JSC::Parser<LexerType>::parseMemberExpression):
3347         * parser/Parser.h:
3348         (JSC::Parser::nextWithoutClearingLineTerminator):
3349         (JSC::Parser::lexCurrentTokenAgainUnderCurrentContext):
3350         (JSC::Parser::internalSaveLexerState):
3351         (JSC::Parser::restoreLexerState):
3352
3353 2019-04-08  Ryan Haddad  <ryanhaddad@apple.com>
3354
3355         Unreviewed, rolling out r243948.
3356
3357         Caused inspector/runtime/parse.html to fail
3358
3359         Reverted changeset:
3360
3361         "SIGSEGV in JSC::BytecodeGenerator::addStringConstant"
3362         https://bugs.webkit.org/show_bug.cgi?id=196486
3363         https://trac.webkit.org/changeset/243948
3364
3365 2019-04-08  Ryan Haddad  <ryanhaddad@apple.com>
3366
3367         Unreviewed, rolling out r243943.
3368
3369         Caused test262 failures.
3370
3371         Reverted changeset:
3372
3373         "[JSC] Filter DontEnum properties in
3374         ProxyObject::getOwnPropertyNames()"
3375         https://bugs.webkit.org/show_bug.cgi?id=176810
3376         https://trac.webkit.org/changeset/243943
3377
3378 2019-04-08  Claudio Saavedra  <csaavedra@igalia.com>
3379
3380         [JSC] Partially fix the build with unified builds disabled
3381         https://bugs.webkit.org/show_bug.cgi?id=196647
3382
3383         Reviewed by Konstantin Tokarev.
3384
3385         If you disable unified builds you find all kind of build
3386         errors. This partially tries to fix them but there's a lot
3387         more.
3388
3389         * API/JSBaseInternal.h:
3390         * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp:
3391         * b3/air/AirHandleCalleeSaves.h:
3392         * bytecode/ExecutableToCodeBlockEdge.cpp:
3393         * bytecode/ExitFlag.h:
3394         * bytecode/ICStatusUtils.h:
3395         * bytecode/UnlinkedMetadataTable.h:
3396         * dfg/DFGPureValue.h:
3397         * heap/IsoAlignedMemoryAllocator.cpp:
3398         * heap/IsoAlignedMemoryAllocator.h:
3399
3400 2019-04-08  Guillaume Emont  <guijemont@igalia.com>
3401
3402         Enable DFG on MIPS
3403         https://bugs.webkit.org/show_bug.cgi?id=196689
3404
3405         Reviewed by Žan Doberšek.
3406
3407         Since the bytecode change, we enabled the baseline JIT on mips in
3408         r240432, but DFG is still missing. With this change, all tests are
3409         passing on a ci20 board.
3410
3411         * jit/RegisterSet.cpp:
3412         (JSC::RegisterSet::calleeSaveRegisters):
3413         Added s0, which is used in llint.
3414
3415 2019-04-08  Xan Lopez  <xan@igalia.com>
3416
3417         [CMake] Detect SSE2 at compile time
3418         https://bugs.webkit.org/show_bug.cgi?id=196488
3419
3420         Reviewed by Carlos Garcia Campos.
3421
3422         * assembler/MacroAssemblerX86Common.cpp: Remove unnecessary (and
3423         incorrect) static_assert.
3424
3425 2019-04-07  Michael Saboff  <msaboff@apple.com>
3426
3427         REGRESSION (r243642): Crash in reddit.com page
3428         https://bugs.webkit.org/show_bug.cgi?id=196684
3429
3430         Reviewed by Geoffrey Garen.
3431
3432         In r243642, the code that saves and restores the count for non-greedy character classes
3433         was inadvertently put inside an if statement.  This code should be generated for all
3434         non-greedy character classes.
3435
3436         * yarr/YarrJIT.cpp:
3437         (JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy):
3438         (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
3439
3440 2019-04-07  Yusuke Suzuki  <ysuzuki@apple.com>
3441
3442         [JSC] CallLinkInfo should clear Callee or CodeBlock even if it is unlinked by jettison
3443         https://bugs.webkit.org/show_bug.cgi?id=196683
3444
3445         Reviewed by Saam Barati.
3446
3447         In r243626, we stop repatching CallLinkInfo when the CallLinkInfo is held by jettisoned CodeBlock.
3448         But we still need to clear the Callee or CodeBlock since they are now dead. Otherwise, CodeBlock's
3449         visitWeak eventually accesses this dead cells and crashes because the owner CodeBlock of CallLinkInfo
3450         can be still live.
3451
3452         We also move all repatching operations from CallLinkInfo.cpp to Repatch.cpp for consistency because the
3453         other repatching operations in CallLinkInfo are implemented in Repatch.cpp side.
3454
3455         * bytecode/CallLinkInfo.cpp:
3456         (JSC::CallLinkInfo::setCallee):
3457         (JSC::CallLinkInfo::clearCallee):
3458         * jit/Repatch.cpp:
3459         (JSC::linkFor):
3460         (JSC::revertCall):
3461
3462 2019-04-05  Yusuke Suzuki  <ysuzuki@apple.com>
3463
3464         [JSC] OSRExit recovery for SpeculativeAdd does not consier "A = A + A" pattern
3465         https://bugs.webkit.org/show_bug.cgi?id=196582
3466
3467         Reviewed by Saam Barati.
3468
3469         In DFG, our ArithAdd with overflow is executed speculatively, and we recover the value when overflow flag is set.
3470         The recovery is subtracting the operand from the destination to get the original two operands. Our recovery code
3471         handles A + B = A, A + B = B cases. But it misses A + A = A case (here, A and B are GPRReg). Our recovery code
3472         attempts to produce the original operand by performing A - A, and it always produces zero accidentally.
3473
3474         This patch adds the recovery code for A + A = A case. Because we know that this ArithAdd overflows, and operands were
3475         same values, we can calculate the original operand from the destination value by `((int32_t)value >> 1) ^ 0x80000000`.
3476
3477         We also found that FTL recovery code is dead. We remove them in this patch.
3478
3479         * dfg/DFGOSRExit.cpp:
3480         (JSC::DFG::OSRExit::executeOSRExit):
3481         (JSC::DFG::OSRExit::compileExit):
3482         * dfg/DFGOSRExit.h:
3483         (JSC::DFG::SpeculationRecovery::SpeculationRecovery):
3484         * dfg/DFGSpeculativeJIT.cpp:
3485         (JSC::DFG::SpeculativeJIT::compileArithAdd):
3486         * ftl/FTLExitValue.cpp:
3487         (JSC::FTL::ExitValue::dataFormat const):
3488         (JSC::FTL::ExitValue::dumpInContext const):
3489         * ftl/FTLExitValue.h:
3490         (JSC::FTL::ExitValue::isArgument const):
3491         (JSC::FTL::ExitValue::hasIndexInStackmapLocations const):
3492         (JSC::FTL::ExitValue::adjustStackmapLocationsIndexByOffset):
3493         (JSC::FTL::ExitValue::recovery): Deleted.
3494         (JSC::FTL::ExitValue::isRecovery const): Deleted.
3495         (JSC::FTL::ExitValue::leftRecoveryArgument const): Deleted.
3496         (JSC::FTL::ExitValue::rightRecoveryArgument const): Deleted.
3497         (JSC::FTL::ExitValue::recoveryFormat const): Deleted.
3498         (JSC::FTL::ExitValue::recoveryOpcode const): Deleted.
3499         * ftl/FTLLowerDFGToB3.cpp:
3500         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3501         (JSC::FTL::DFG::LowerDFGToB3::preparePatchpointForExceptions):
3502         (JSC::FTL::DFG::LowerDFGToB3::appendOSRExit):
3503         (JSC::FTL::DFG::LowerDFGToB3::exitValueForNode):
3504         (JSC::FTL::DFG::LowerDFGToB3::addAvailableRecovery): Deleted.
3505         * ftl/FTLOSRExitCompiler.cpp:
3506         (JSC::FTL::compileRecovery):
3507
3508 2019-04-05  Ryan Haddad  <ryanhaddad@apple.com>
3509
3510         Unreviewed, rolling out r243665.
3511
3512         Caused iOS JSC tests to exit with an exception.
3513
3514         Reverted changeset:
3515
3516         "Assertion failed in JSC::createError"
3517         https://bugs.webkit.org/show_bug.cgi?id=196305
3518         https://trac.webkit.org/changeset/243665
3519
3520 2019-04-05  Yusuke Suzuki  <ysuzuki@apple.com>
3521
3522         SIGSEGV in JSC::BytecodeGenerator::addStringConstant
3523         https://bugs.webkit.org/show_bug.cgi?id=196486
3524
3525         Reviewed by Saam Barati.
3526
3527         When parsing a FunctionExpression / FunctionDeclaration etc., we use SyntaxChecker for the body of the function because we do not have any interest on the nodes of the body at that time.
3528         The nodes will be parsed with the ASTBuilder when the function itself is parsed for code generation. This works well previously because all the function ends with "}" previously.
3529         SyntaxChecker lexes this "}" token, and parser restores the context back to ASTBuilder and continues parsing.
3530
3531         But now, we have ArrowFunctionExpression without braces `arrow => expr`. Let's consider the following code.
3532
3533                 arrow => expr
3534                 "string!"
3535
3536         We parse arrow function's body with SyntaxChecker. At that time, we lex "string!" token under the SyntaxChecker context. But this means that we may not build string content for this token
3537         since SyntaxChecker may not have interest on string content itself in certain case. After the parser is back to ASTBuilder, we parse "string!" as ExpressionStatement with string constant,
3538         generate StringNode with non-built identifier (nullptr), and we accidentally create StringNode with nullptr.
3539
3540         This patch fixes this problem. The root cause of this problem is that the last token lexed in the previous context is used. We add lexCurrentTokenAgainUnderCurrentContext which will re-lex
3541         the current token under the current context (may be ASTBuilder). This should be done only when the caller's context is different from SyntaxChecker, which avoids unnecessary lexing.
3542         We leverage existing SavePoint mechanism to implement lexCurrentTokenAgainUnderCurrentContext cleanly.
3543
3544         And we also fix the bug in the existing SavePoint mechanism, which is shown in the attached test script. When we save LexerState, we do not save line terminator status. This patch also introduces
3545         lexWithoutClearingLineTerminator, which lex the token without clearing line terminator status.
3546
3547         * parser/ASTBuilder.h:
3548         (JSC::ASTBuilder::createString):
3549         * parser/Lexer.cpp:
3550         (JSC::Lexer<T>::parseMultilineComment):
3551         (JSC::Lexer<T>::lexWithoutClearingLineTerminator): EOF token also should record offset information. This offset information is correctly handled in Lexer::setOffset too.
3552         (JSC::Lexer<T>::lex): Deleted.
3553         * parser/Lexer.h:
3554         (JSC::Lexer::hasLineTerminatorBeforeToken const):
3555         (JSC::Lexer::setHasLineTerminatorBeforeToken):
3556         (JSC::Lexer<T>::lex):
3557         (JSC::Lexer::prevTerminator const): Deleted.
3558         (JSC::Lexer::setTerminator): Deleted.
3559         * parser/Parser.cpp:
3560         (JSC::Parser<LexerType>::allowAutomaticSemicolon):
3561         (JSC::Parser<LexerType>::parseSingleFunction):
3562         (JSC::Parser<LexerType>::parseStatementListItem):
3563         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
3564         (JSC::Parser<LexerType>::parseFunctionInfo):
3565         (JSC::Parser<LexerType>::parseClass):
3566         (JSC::Parser<LexerType>::parseExportDeclaration):
3567         (JSC::Parser<LexerType>::parseAssignmentExpression):
3568         (JSC::Parser<LexerType>::parseYieldExpression):
3569         (JSC::Parser<LexerType>::parseProperty):
3570         (JSC::Parser<LexerType>::parsePrimaryExpression):
3571         (JSC::Parser<LexerType>::parseMemberExpression):
3572         * parser/Parser.h:
3573         (JSC::Parser::nextWithoutClearingLineTerminator):
3574         (JSC::Parser::lexCurrentTokenAgainUnderCurrentContext):
3575         (JSC::Parser::internalSaveLexerState):
3576         (JSC::Parser::restoreLexerState):
3577
3578 2019-04-05  Caitlin Potter  <caitp@igalia.com>
3579
3580         [JSC] Filter DontEnum properties in ProxyObject::getOwnPropertyNames()
3581         https://bugs.webkit.org/show_bug.cgi?id=176810
3582
3583         Reviewed by Saam Barati.
3584
3585         This adds conditional logic following the invariant checks, to perform
3586         filtering in common uses of getOwnPropertyNames.
3587
3588         While this would ideally only be done in JSPropertyNameEnumerator, adding
3589         the filtering to ProxyObject::performGetOwnPropertyNames maintains the
3590         invariant that the EnumerationMode is properly followed.
3591
3592         * runtime/PropertyNameArray.h:
3593         (JSC::PropertyNameArray::reset):
3594         * runtime/ProxyObject.cpp:
3595         (JSC::ProxyObject::performGetOwnPropertyNames):
3596
3597 2019-04-05  Commit Queue  <commit-queue@webkit.org>
3598
3599         Unreviewed, rolling out r243833.
3600         https://bugs.webkit.org/show_bug.cgi?id=196645
3601
3602         This change breaks build of WPE and GTK ports (Requested by
3603         annulen on #webkit).
3604
3605         Reverted changeset:
3606
3607         "[CMake][WTF] Mirror XCode header directories"
3608         https://bugs.webkit.org/show_bug.cgi?id=191662
3609         https://trac.webkit.org/changeset/243833
3610
3611 2019-04-05  Caitlin Potter  <caitp@igalia.com>
3612
3613         [JSC] throw if ownKeys Proxy trap result contains duplicate keys
3614         https://bugs.webkit.org/show_bug.cgi?id=185211
3615
3616         Reviewed by Saam Barati.
3617
3618         Implements the normative spec change in https://github.com/tc39/ecma262/pull/833
3619
3620         This involves tracking duplicate keys returned from the ownKeys trap in yet
3621         another HashTable, and may incur a minor performance penalty in some cases. This
3622         is not expected to significantly affect web performance.
3623
3624         * runtime/ProxyObject.cpp:
3625         (JSC::ProxyObject::performGetOwnPropertyNames):
3626
3627 2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>
3628
3629         [JSC] makeBoundFunction should not assume incoming "length" value is Int32 because it performs some calculation in bytecode
3630         https://bugs.webkit.org/show_bug.cgi?id=196631
3631
3632         Reviewed by Saam Barati.
3633
3634         makeBoundFunction assumes that "length" argument is always Int32. But this should not be done since this "length" value is calculated in builtin JS code.
3635         DFG may store this value in Double format so that we should not rely on that this value is Int32. This patch fixes makeBoundFunction function to perform
3636         toInt32 operation. We also insert a missing exception check for `JSString::value(ExecState*)` in makeBoundFunction.
3637
3638         * JavaScriptCore.xcodeproj/project.pbxproj:
3639         * Sources.txt:
3640         * interpreter/CallFrameInlines.h:
3641         * runtime/DoublePredictionFuzzerAgent.cpp: Copied from Source/JavaScriptCore/interpreter/CallFrameInlines.h.
3642         (JSC::DoublePredictionFuzzerAgent::DoublePredictionFuzzerAgent):
3643         (JSC::DoublePredictionFuzzerAgent::getPrediction):
3644         * runtime/DoublePredictionFuzzerAgent.h: Copied from Source/JavaScriptCore/interpreter/CallFrameInlines.h.
3645         * runtime/JSGlobalObject.cpp:
3646         (JSC::makeBoundFunction):
3647         * runtime/Options.h:
3648         * runtime/VM.cpp:
3649         (JSC::VM::VM):
3650
3651 2019-04-04  Robin Morisset  <rmorisset@apple.com>
3652
3653         B3ReduceStrength should know that Mul distributes over Add and Sub
3654         https://bugs.webkit.org/show_bug.cgi?id=196325
3655         <rdar://problem/49441650>
3656
3657         Reviewed by Saam Barati.
3658
3659         Fix some obviously wrong code that was due to an accidental copy-paste.
3660         It made the entire optimization dead code that never ran.
3661
3662         * b3/B3ReduceStrength.cpp:
3663
3664 2019-04-04  Saam Barati  <sbarati@apple.com>
3665
3666         Unreviewed, build fix for CLoop after r243886
3667
3668         * interpreter/Interpreter.cpp:
3669         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
3670         * interpreter/StackVisitor.cpp:
3671         (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
3672         * interpreter/StackVisitor.h:
3673
3674 2019-04-04  Commit Queue  <commit-queue@webkit.org>
3675
3676         Unreviewed, rolling out r243898.
3677         https://bugs.webkit.org/show_bug.cgi?id=196624
3678
3679         `#if !ENABLE(C_LOOP) && NUMBER_OF_CALLEE_SAVES_REGISTERS > 0`
3680         does not work well (Requested by yusukesuzuki on #webkit).
3681
3682         Reverted changeset:
3683
3684         "Unreviewed, build fix for CLoop and Windows after r243886"
3685         https://bugs.webkit.org/show_bug.cgi?id=196387
3686         https://trac.webkit.org/changeset/243898
3687
3688 2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>
3689
3690         Unreviewed, build fix for CLoop and Windows after r243886
3691         https://bugs.webkit.org/show_bug.cgi?id=196387
3692
3693         RegisterAtOffsetList does not exist if ENABLE(ASSEMBLER) is false.
3694
3695         * interpreter/StackVisitor.cpp:
3696         (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
3697         * interpreter/StackVisitor.h:
3698
3699 2019-04-04  Saam barati  <sbarati@apple.com>
3700
3701         Teach Call ICs how to call Wasm
3702         https://bugs.webkit.org/show_bug.cgi?id=196387
3703
3704         Reviewed by Filip Pizlo.
3705
3706         This patch teaches JS to call Wasm without going through the native thunk.
3707         Currently, we emit a JIT "JS" callee stub which marshals arguments from
3708         JS to Wasm. Like the native version of this, this thunk is responsible
3709         for saving and restoring the VM's current Wasm context. Instead of emitting
3710         an exception handler, we also teach the unwinder how to read the previous
3711         wasm context to restore it as it unwindws past this frame.
3712         
3713         This patch is straight forward, and leaves some areas for perf improvement:
3714         - We can teach the DFG/FTL to directly use the Wasm calling convention when
3715           it knows it's calling a single Wasm function. This way we don't shuffle
3716           registers to the stack and then back into registers.
3717         - We bail out to the slow path for mismatched arity. I opened a bug to fix
3718           optimize arity check failures: https://bugs.webkit.org/show_bug.cgi?id=196564
3719         - We bail out to the slow path Double JSValues flowing into i32 arguments.
3720           We should teach this thunk how to do that conversion directly.
3721         
3722         This patch also refactors the code to explicitly have a single pinned size register.
3723         We used pretend in some places that we could have more than one pinned size register.
3724         However, there was other code that just asserted the size was one. This patch just rips
3725         out this code since we never moved to having more than one pinned size register. Doing
3726         this refactoring cleans up the various places where we set up the size register.
3727         
3728         This patch is a 50-60% progression on JetStream 2's richards-wasm.
3729
3730         * JavaScriptCore.xcodeproj/project.pbxproj:
3731         * Sources.txt:
3732         * assembler/MacroAssemblerCodeRef.h:
3733         (JSC::MacroAssemblerCodeRef::operator=):
3734         (JSC::MacroAssemblerCodeRef::MacroAssemblerCodeRef):
3735         * interpreter/Interpreter.cpp:
3736         (JSC::UnwindFunctor::operator() const):
3737         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
3738         * interpreter/StackVisitor.cpp:
3739         (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
3740         (JSC::StackVisitor::Frame::calleeSaveRegisters): Deleted.
3741         * interpreter/StackVisitor.h:
3742         * jit/JITOperations.cpp:
3743         * jit/RegisterSet.cpp:
3744         (JSC::RegisterSet::runtimeTagRegisters):
3745         (JSC::RegisterSet::specialRegisters):
3746         (JSC::RegisterSet::runtimeRegisters): Deleted.
3747         * jit/RegisterSet.h:
3748         * jit/Repatch.cpp:
3749         (JSC::linkPolymorphicCall):
3750         * runtime/JSFunction.cpp:
3751         (JSC::getCalculatedDisplayName):
3752         * runtime/JSGlobalObject.cpp:
3753         (JSC::JSGlobalObject::init):
3754         (JSC::JSGlobalObject::visitChildren):
3755         * runtime/JSGlobalObject.h:
3756         (JSC::JSGlobalObject::jsToWasmICCalleeStructure const):
3757         * runtime/VM.cpp:
3758         (JSC::VM::VM):
3759         * runtime/VM.h:
3760         * wasm/WasmAirIRGenerator.cpp:
3761         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
3762         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
3763         (JSC::Wasm::AirIRGenerator::addCallIndirect):
3764         * wasm/WasmB3IRGenerator.cpp:
3765         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
3766         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
3767         (JSC::Wasm::B3IRGenerator::addCallIndirect):
3768         * wasm/WasmBinding.cpp:
3769         (JSC::Wasm::wasmToWasm):
3770         * wasm/WasmContext.h:
3771         (JSC::Wasm::Context::pointerToInstance):
3772         * wasm/WasmContextInlines.h:
3773         (JSC::Wasm::Context::store):
3774         * wasm/WasmMemoryInformation.cpp:
3775         (JSC::Wasm::getPinnedRegisters):
3776         (JSC::Wasm::PinnedRegisterInfo::get):
3777         (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
3778         * wasm/WasmMemoryInformation.h:
3779         (JSC::Wasm::PinnedRegisterInfo::toSave const):
3780         * wasm/WasmOMGPlan.cpp:
3781         (JSC::Wasm::OMGPlan::work):
3782         * wasm/js/JSToWasm.cpp:
3783         (JSC::Wasm::createJSToWasmWrapper):
3784         * wasm/js/JSToWasmICCallee.cpp: Added.
3785         (JSC::JSToWasmICCallee::create):
3786         (JSC::JSToWasmICCallee::createStructure):
3787         (JSC::JSToWasmICCallee::visitChildren):
3788         * wasm/js/JSToWasmICCallee.h: Added.
3789         (JSC::JSToWasmICCallee::function):
3790         (JSC::JSToWasmICCallee::JSToWasmICCallee):
3791         * wasm/js/WebAssemblyFunction.cpp:
3792         (JSC::WebAssemblyFunction::useTagRegisters const):
3793         (JSC::WebAssemblyFunction::calleeSaves const):
3794         (JSC::WebAssemblyFunction::usedCalleeSaveRegisters const):
3795         (JSC::WebAssemblyFunction::previousInstanceOffset const):
3796         (JSC::WebAssemblyFunction::previousInstance):
3797         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
3798         (JSC::WebAssemblyFunction::visitChildren):
3799         (JSC::WebAssemblyFunction::destroy):
3800         * wasm/js/WebAssemblyFunction.h:
3801         * wasm/js/WebAssemblyFunctionHeapCellType.cpp: Added.
3802         (JSC::WebAssemblyFunctionDestroyFunc::operator() const):
3803         (JSC::WebAssemblyFunctionHeapCellType::WebAssemblyFunctionHeapCellType):
3804         (JSC::WebAssemblyFunctionHeapCellType::~WebAssemblyFunctionHeapCellType):
3805         (JSC::WebAssemblyFunctionHeapCellType::finishSweep):
3806         (JSC::WebAssemblyFunctionHeapCellType::destroy):
3807         * wasm/js/WebAssemblyFunctionHeapCellType.h: Added.
3808         * wasm/js/WebAssemblyPrototype.h:
3809
3810 2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>
3811
3812         [JSC] Pass CodeOrigin to FuzzerAgent
3813         https://bugs.webkit.org/show_bug.cgi?id=196590
3814
3815         Reviewed by Saam Barati.
3816
3817         Pass CodeOrigin instead of bytecodeIndex. CodeOrigin includes richer information (InlineCallFrame*).
3818         We also mask prediction with SpecBytecodeTop in DFGByteCodeParser. The fuzzer can produce any SpeculatedTypes,
3819         but DFGByteCodeParser should only see predictions that can be actually produced from the bytecode execution.
3820
3821         * dfg/DFGByteCodeParser.cpp:
3822         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
3823         * runtime/FuzzerAgent.cpp:
3824         (JSC::FuzzerAgent::getPrediction):
3825         * runtime/FuzzerAgent.h:
3826         * runtime/RandomizingFuzzerAgent.cpp:
3827         (JSC::RandomizingFuzzerAgent::getPrediction):
3828         * runtime/RandomizingFuzzerAgent.h:
3829
3830 2019-04-04  Caio Lima  <ticaiolima@gmail.com>
3831
3832         [JSC] We should consider moving UnlinkedFunctionExecutable::m_parentScopeTDZVariables to RareData
3833         https://bugs.webkit.org/show_bug.cgi?id=194944
3834
3835         Reviewed by Keith Miller.
3836
3837         Based on profile data collected on JetStream2, Speedometer 2 and
3838         other benchmarks, it is very rare having non-empty
3839         UnlinkedFunctionExecutable::m_parentScopeTDZVariables.
3840
3841         - Data collected from Speedometer2
3842             Total number of UnlinkedFunctionExecutable: 39463
3843             Total number of non-empty parentScopeTDZVars: 428 (~1%)
3844
3845         - Data collected from JetStream2
3846             Total number of UnlinkedFunctionExecutable: 83715
3847             Total number of non-empty parentScopeTDZVars: 5285 (~6%)
3848
3849         We also collected numbers on 6 of top 10 Alexia sites.
3850
3851         - Data collected from youtube.com
3852             Total number of UnlinkedFunctionExecutable: 29599
3853             Total number of non-empty parentScopeTDZVars: 97 (~0.3%)
3854
3855         - Data collected from twitter.com
3856             Total number of UnlinkedFunctionExecutable: 23774
3857             Total number of non-empty parentScopeTDZVars: 172 (~0.7%)
3858
3859         - Data collected from google.com
3860             Total number of UnlinkedFunctionExecutable: 33209
3861             Total number of non-empty parentScopeTDZVars: 174 (~0.5%)
3862
3863         - Data collected from amazon.com:
3864             Total number of UnlinkedFunctionExecutable: 15182
3865             Total number of non-empty parentScopeTDZVars: 166 (~1%)
3866
3867         - Data collected from facebook.com:
3868             Total number of UnlinkedFunctionExecutable: 54443
3869             Total number of non-empty parentScopeTDZVars: 269 (~0.4%)