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