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